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

Votre modèle de données de gestion des dépenses

Ramp

Attributs de la gestion des dépenses (19) Activités de gestion des dépenses (12) Guides d’extraction (3)

Votre modèle de données de gestion des dépenses

Ce modèle fournit une feuille de route claire pour collecter les données nécessaires à l’analyse et à l’optimisation de votre processus de gestion des dépenses. Il présente les attributs essentiels, les principales activités à suivre et des conseils pratiques pour extraire vos données de Ramp. Utilisez cette ressource pour vous assurer de réunir toutes les informations nécessaires à une découverte et à une amélioration pertinentes du processus.

Attributs recommandés à collecter
Activités clés à suivre
Recommandations pour l’extraction depuis Ramp

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de la gestion des dépenses

Voici les champs de données essentiels à inclure dans votre journal d’événements pour analyser en détail votre processus de gestion des dépenses.

3 Obligatoire 6 Recommandé 10 Facultatif

	Nom	Description
	Horodatage de l’événement EventTimestamp	La date et l’heure exactes auxquelles l’activité s’est produite.
Description Chaque activité du processus possède un horodatage correspondant qui indique le moment où elle s’est produite. Ces données temporelles servent à classer les événements par ordre chronologique et constituent la base de toutes les analyses liées au temps. Dans le process mining, les horodatages servent à calculer les délais entre les activités, à mesurer la durée totale d’un dossier et à identifier les retards. Ces informations sont essentielles au suivi de la performance et à l’identification des possibilités d’amélioration du processus. Pourquoi c’est important Cet Attribut fournit l’ordre chronologique des événements et est indispensable à tous les calculs de durée et à l’analyse de la performance. Où les obtenir Ces informations se trouvent généralement avec les 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
	Identifiant de la note de frais ExpenseReportId	L’identifiant unique de chaque note de frais, qui sert d’identifiant principal du dossier dans le processus.
Description L’Expense Report ID regroupe tous les événements et activités associés à une même soumission de dépenses. Il permet de suivre intégralement et chronologiquement une demande de remboursement, de sa saisie 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 identifiant de dossier, les analyses peuvent calculer précisément les délais de traitement, identifier les goulots d’étranglement et visualiser les différents circuits suivis par les notes de frais dans le processus d’approbation. Pourquoi c’est important Il s’agit de l’Attribut fondamental qui relie toutes les activités associées au sein d’une même instance de processus et rend possible l’analyse de bout en bout. Où les obtenir Cet identifiant doit être disponible dans la table principale des notes de frais ou des transactions 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 précise qui s’est produit à un moment donné du processus de gestion des dépenses.
Description Cet attribut décrit une étape du cycle de vie d’une note de frais, comme « Expense Submitted », « Manager Approved » ou « Reimbursement Executed ». Ces activités constituent les nœuds de la cartographie du processus et permettent de visualiser et d’analyser le flux du processus. L’analyse des activités aide à identifier les étapes les plus fréquentes, à localiser les goulots d’étranglement et à comprendre les variations entre les différents flux de travail. Il s’agit d’un composant essentiel pour comprendre la séquence des opérations et mesurer les performances à chaque étape. Pourquoi c’est important Il définit les étapes de la cartographie du processus et permet de visualiser et d’analyser son déroulement du début à la fin. Où les obtenir Il 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ée par le responsableEn attente d’examen financierRemboursement exécuté
	Catégorie de dépenses ExpenseCategory	La catégorie attribuée à une dépense, par exemple « Travel », « Software » ou « Meals ».
Description Cet attribut classe les dépenses dans des catégories prédéfinies, ce qui facilite le suivi et le contrôle des dépenses de l’entreprise. Un même rapport de dépenses peut contenir des éléments appartenant à plusieurs catégories. L’analyse par catégorie de dépenses est essentielle au Dashboard « Spend Category Analysis ». Elle aide les équipes financières à comprendre où les fonds sont dépensés, à suivre le respect du budget et à repérer les tendances ou les anomalies au fil du temps. Pourquoi c’est important Il permet d’analyser les dépenses en détail, afin d’identifier les principaux facteurs de coût et les possibilités d’optimisation budgétaire. Où les obtenir Il s’agit généralement d’un détail au niveau de la ligne d’article du rapport de dépenses dans Ramp. Pour certaines analyses, les données doivent être agrégées au niveau du rapport. Exemples Billets d’avionRepas et représentationAbonnement logicielFournitures de bureau
	Indicateur de non-respect de la politique PolicyViolationFlag	Indicateur précisant si le rapport de dépenses a été signalé pour non-respect d’une politique.
Description Cet attribut booléen prend la valeur true lorsque les contrôles automatisés du système détectent un non-respect potentiel des politiques de dépenses de l’entreprise, par exemple le dépassement d’une limite de dépenses ou la soumission d’une dépense en double. Cet indicateur est essentiel au Dashboard « Policy Violation Detection » et au KPI associé. Il aide à mesurer l’efficacité des contrôles et à repérer les cas fréquents de non-conformité, afin d’éclairer la mise à jour des politiques ou la formation des collaborateurs. Pourquoi c’est important Il mesure directement le respect des politiques et aide à repérer et à réduire les dépenses non conformes ainsi que les risques associés. Où les obtenir Il s’agit vraisemblablement d’un indicateur généré par le système dans Ramp, déclenché par des contrôles automatisés lors de la soumission ou de l’approbation. Exemples truefalse
	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 même rapport. Il s’agit d’un indicateur financier important pour comprendre les habitudes de dépenses. Dans l’analyse des processus, le montant du rapport peut servir à segmenter les cas et à déterminer si les rapports de montant élevé suivent des circuits d’approbation différents ou nécessitent davantage de temps de traitement. Il est essentiel aux Dashboards d’analyse des dépenses et à l’identification des possibilités de réduction des coûts. Pourquoi c’est important Il fournit une dimension financière importante pour l’analyse, en permettant de segmenter les rapports par montant et de suivre les dépenses globales. Où les obtenir Il s’agit d’un champ principal de l’objet de rapport de dépenses dans Ramp. Exemples 150.752500.0089.99
	Motif de révision RevisionReason	Le motif indiqué lorsqu’un rapport de dépenses est renvoyé au collaborateur pour révision.
Description Lorsqu’un approbateur rejette ou renvoie un rapport de dépenses, il indique généralement un motif. Cet attribut enregistre ce motif, par exemple « Missing Receipt », « Incorrect Category » ou « Out of Policy ». Ces informations sont particulièrement utiles pour le Dashboard « Expense Revision Rate & Causes ». En analysant les motifs de reprise les plus fréquents, les organisations peuvent repérer les problèmes systémiques du processus de soumission et mettre en place des formations ciblées ou des améliorations du système afin de réduire les erreurs. Pourquoi c’est important Il fournit une visibilité directe sur les causes profondes des reprises et permet de mettre en place des mesures ciblées pour améliorer la qualité des soumissions dès la première tentative. Où les obtenir Ces données seraient enregistrées dans les commentaires ou les détails du rejet lorsque l’activité « Expense Sent Back for Revision » se produit dans Ramp. Exemples Justificatif détaillé manquantDépense dépassant le plafond de la politiqueCatégorie de dépense incorrecte sélectionnéeTransaction en double
	Nom de l’utilisateur UserName	Le nom ou l’identifiant de l’utilisateur qui a effectué l’activité, notamment l’employé ayant soumis la dépense ou l’approbateur.
Description Cet Attribut identifie la personne responsable d’un événement donné du processus, par exemple la soumission, l’approbation ou l’examen d’une note de frais. Il peut s’agir du nom de l’employé ou d’un identifiant utilisateur unique. L’analyse par utilisateur permet de comprendre la répartition de la charge, d’identifier les personnes les plus performantes et de repérer celles qui pourraient avoir besoin d’une formation complémentaire. Elle est essentielle pour les Dashboards consacrés à la performance des approbations et à la gestion des Ressources. Pourquoi c’est important Il associe les activités du processus à des personnes précises, ce qui permet d’analyser la performance au niveau des Ressources et d’identifier les besoins de formation. Où les obtenir Les informations utilisateur sont généralement enregistrées dans la piste d’audit ou l’historique des transactions de chaque note de frais dans Ramp. Exemples Alice JohnsonBob SmithCharlie BrownAutomatisation du système
	Service de l’employé EmployeeDepartment	Le service de l’employé qui a soumis la note de frais.
Description Cet Attribut indique l’unité opérationnelle ou le service auquel appartient l’employé ayant soumis la dépense, par exemple « Sales », « Engineering » ou « Marketing ». Il s’agit d’une dimension importante pour l’analyse, car elle permet de filtrer et de comparer la performance du processus entre les différentes composantes de l’organisation. Elle peut révéler des écarts de délai d’approbation, de taux de correction et de respect des politiques entre les services, afin de soutenir des initiatives d’amélioration ciblées. Pourquoi c’est important Il permet de comparer les indicateurs du processus entre différentes unités opérationnelles et de mettre en évidence les écarts d’efficacité, de Conformité et de dépenses. Où les obtenir Ces informations sont probablement associées au profil utilisateur de l’employé dans Ramp ou dans un système RH intégré. Exemples VentesMarketingIngénierieFinance
	Approbateur financier FinanceApprover	L’utilisateur de l’équipe financière qui a approuvé le rapport de dépenses.
Description Pour les flux de travail qui comprennent une étape de contrôle financier, cet attribut identifie la personne ou l’équipe précise du service financier qui a effectué l’approbation finale. Cet attribut alimente le Dashboard « Finance Review Efficiency » en permettant d’analyser les performances au niveau individuel ou au niveau de l’é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 contrôle financier. Pourquoi c’est important Il permet d’analyser en détail la performance de l’étape d’examen financier et d’optimiser un point de contrôle important du processus. Où les obtenir Ces informations seraient enregistrées dans l’historique des approbations du rapport de dépenses dans Ramp, lors de l’étape d’examen financier. Exemples Équipe Finance ADavid LeeBot d’automatisation Finance
	Dernière mise à jour des données LastDataUpdate	L’horodatage indiquant la dernière actualisation des données depuis le système source.
Description Cet Attribut enregistre la date et l’heure de l’extraction de données la plus récente. Il fournit un contexte sur l’actualité des données analysées. Dans toute analyse, il est essentiel de connaître la fraîcheur des données pour interpréter correctement les résultats. Cet Attribut aide les utilisateurs à déterminer s’ils consultent des informations à jour. Pourquoi c’est important Il informe les utilisateurs sur l’actualité des données et garantit que les analyses reposent sur des informations actuelles et pertinentes. Où les obtenir Cet horodatage est généré et ajouté lors de l’extraction des données. Exemples 2023-11-01T06:00:00Z
	Heure de fin de l’événement EventEndTime	L’horodatage indiquant la fin d’une activité ayant une durée.
Description De nombreuses activités sont instantanées, mais certaines, comme « Policy Check Performed », peuvent avoir une durée mesurable. Cet attribut enregistre l’heure de fin de ces activités et complète StartTime. La présence d’une heure de début et d’une heure de fin permet de calculer précisément les temps de traitement des activités. Elle est essentielle aux KPI tels que « Average Policy Check Duration » et permet de déterminer exactement le temps nécessaire à l’exécution de certaines tâches automatisées ou manuelles dans l’ensemble du processus. Pourquoi c’est important Il permet de calculer précisément la durée de chaque activité et d’identifier les étapes inefficaces du processus. Où les obtenir Pour les activités ayant une durée, cette information serait enregistrée dans les données d’événements de Ramp. Pour les événements instantanés, elle peut être identique à StartTime. Exemples 2023-10-26T10:00:05Z2023-10-26T14:35:10Z2023-10-27T09:10:00Z
	Mode de remboursement ReimbursementMethod	Le mode utilisé pour effectuer le paiement du remboursement, par exemple ACH ou virement bancaire.
Description Cet attribut précise le canal de paiement par lequel le collaborateur a été remboursé. Les différents modes peuvent présenter des délais de traitement et des coûts distincts. L’analyse de la performance des remboursements par mode permet d’identifier les canaux de paiement les plus efficaces. Le Dashboard « Reimbursement Method Performance » utilise ces données pour comparer les délais de traitement et la fiabilité, ce qui peut contribuer à optimiser les stratégies de paiement. Pourquoi c’est important Il permet de comparer la performance des différents canaux de paiement afin d’optimiser la rapidité et la fiabilité. Où les obtenir Ces informations devraient être disponibles dans les enregistrements de paiement ou de remboursement de Ramp. Exemples Virement ACHCrédit sur carte bancaire d’entrepriseVirement automatique
	Mode de soumission SubmissionMethod	Le canal par lequel le rapport de dépenses a été soumis, par exemple une application mobile ou un portail web.
Description Cet attribut indique comment le collaborateur a soumis son rapport de dépenses. Les modes courants comprennent l’utilisation d’une application mobile, d’un navigateur web sur ordinateur ou le transfert par e-mail. L’analyse du mode de soumission peut fournir des informations sur le comportement des utilisateurs et l’adoption des technologies. Par exemple, un taux élevé de révisions pour les rapports soumis via un canal donné peut révéler des problèmes d’ergonomie dans l’interface de ce canal. Pourquoi c’est important Il fournit un contexte sur le comportement des utilisateurs et peut aider à déterminer si certains canaux de soumission sont associés à davantage d’erreurs ou de retards. Où les obtenir Ces informations peuvent être enregistrées dans les métadonnées de l’événement de soumission des journaux système de Ramp. Exemples Application mobilePortail webE-mail
	Nombre d’étapes d’approbation ApprovalStepCount	Le nombre total d’étapes d’approbation formelles suivies par un rapport de dépenses.
Description Cette métrique calculée compte le nombre d’activités d’approbation distinctes, comme « Manager Approved » et « Finance Approved », qui ont eu lieu pour une seule note de frais. Elle aide à quantifier la complexité du flux de travail d’approbation. Cet attribut est utilisé pour l’indicateur clé de performance « Average Approval Steps per Report » et le Dashboard « Simple Expense Approval Paths ». En analysant ce nombre, notamment par rapport au montant ou à la catégorie de la note de frais, les organisations peuvent déterminer si des dépenses simples et de faible montant sont soumises à des processus d’approbation excessivement complexes. Pourquoi c’est important Il quantifie la complexité du flux de travail et aide à identifier les possibilités de simplification, notamment pour les notes de frais présentant peu de risques. Où les obtenir Il est calculé en comptant les occurrences d’activités spécifiques liées à l’approbation dans chaque cas du journal d’événements. Exemples 123
	Reprise nécessaire IsRework	Indicateur calculé précisant si un rapport de dépenses a été renvoyé au moins une fois pour révision.
Description Cet attribut booléen est calculé en vérifiant si l’activité « Expense Sent Back for Revision » s’est produite pour un cas donné. Il prend la valeur true pour tout rapport ayant fait l’objet d’au moins un cycle de révision. Cet indicateur simplifie le calcul du KPI « Expense Report Revision Rate » et facilite le filtrage et la comparaison entre les rapports approuvés dès la première soumission et ceux ayant nécessité une reprise. L’analyse de ces deux groupes peut révéler l’impact des révisions sur les délais et les coûts. Pourquoi c’est important Il permet de segmenter facilement le processus pour analyser les reprises et de quantifier la fréquence et l’impact des rapports renvoyés pour correction. Où les obtenir Il s’agit d’un champ calculé, obtenu lors de la transformation des données en vérifiant la présence d’une activité de révision dans le cas. Exemples truefalse
	Responsable de l’approbation ApprovingManager	Le nom du responsable qui a effectué l’étape d’approbation.
Description Cet attribut identifie le responsable chargé d’examiner et d’approuver le rapport de dépenses d’un collaborateur. Il se distingue de l’utilisateur qui a soumis le rapport. Le suivi du responsable de l’approbation est essentiel au Dashboard « Manager Approval Cycle Time ». Il permet d’analyser la charge et la performance des approbations, en mettant en évidence les responsables qui approuvent rapidement et ceux qui constituent des goulots d’étranglement. Ces informations peuvent aider à mieux répartir la charge ou à fournir un accompagnement supplémentaire. Pourquoi c’est important Il permet d’analyser les performances de chaque approbateur, afin d’identifier et de traiter les goulots d’étranglement du flux de travail d’approbation. Où les obtenir Ces informations font partie des données du flux de travail d’approbation dans Ramp. Elles sont enregistrées lorsqu’un responsable intervient sur une note de frais. Exemples Jane DoeJohn MillerSusan Chen
	Résultat de l’audit AuditOutcome	Le résultat d’un audit interne ou externe du rapport de dépenses.
Description Pour les rapports de dépenses soumis à un audit formel, cet attribut enregistre le résultat final, par exemple « Approved », « Partially Denied » ou « Further Information Required ». Ces données sont au cœur du Dashboard « Expense Audit Performance ». Elles permettent d’évaluer l’efficacité du processus d’audit, de suivre la fréquence des différents résultats et de 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, en fournissant des analyses sur la conformité et les faiblesses des contrôles. Où les obtenir Ce résultat serait enregistré dans le module d’audit de Ramp ou dans un système intégré utilisé pour l’audit détaillé des dépenses. Exemples ValidéValidé avec remarquesRejetéeTransmise au niveau supérieur
	Système source SourceSystem	Identifie l’application source depuis laquelle les données ont été extraites.
Description Cet Attribut précise le système de référence des données du processus, qui est ici Ramp. Il est utile dans les environnements où les données peuvent provenir de plusieurs systèmes, car il garantit une traçabilité claire. Pour l’analyse, il permet de filtrer les données provenant d’une source précise et peut servir à la validation des données et à la gouvernance. Pourquoi c’est important Il fournit le contexte sur l’origine des données, ce qui est essentiel pour la gouvernance des données et l’intégration de données provenant de plusieurs systèmes. Où les obtenir Il s’agit généralement d’une valeur statique (« Ramp ») ajoutée lors de l’extraction et de la transformation des données. Exemples Ramp

Obligatoire Recommandé Facultatif

Activités de gestion des dépenses

Voici les principales étapes et les jalons du processus à enregistrer dans votre journal d’événements pour reconstituer précisément le processus et mesurer ses performances.

5 Recommandé 7 Facultatif

	Activité	Description
	Approuvée par le responsable	Le responsable a examiné et approuvé la dépense, qui peut ainsi passer à l’étape suivante, par exemple le contrôle financier ou le remboursement. Cet événement est enregistré à la suite d’une action explicite de l’utilisateur.
Pourquoi c’est important Il s’agit d’un jalon important qui indique que le premier niveau d’approbation a été franchi avec succès. Il est essentiel pour analyser les flux de travail d’approbation et identifier les goulots d’étranglement. Où les obtenir Enregistré comme événement dans l’historique d’approbation de la dépense lorsque le responsable clique sur « Approve ». L’Event Log doit contenir l’identifiant de l’approbateur et un horodatage. Collecte Un événement est enregistré lorsqu’un utilisateur disposant des droits d’un responsable effectue l’action « Approve ». Type d’événement explicit
	Dépense engagée	Indique la création d’une dépense, généralement déclenchée automatiquement lors de l’utilisation d’une carte professionnelle ou lorsqu’un employé crée manuellement une dépense personnelle à rembourser. Cet événement est habituellement enregistré à partir des flux de données de transaction ou des actions effectuées dans l’interface utilisateur.
Pourquoi c’est important Il s’agit de l’événement de début principal du cycle de vie d’une dépense. L’analyse du délai à partir de cet événement permet de comprendre les retards de soumission et la vitesse globale du processus. Où les obtenir Généré à partir des journaux de transactions de carte Ramp ou de l’horodatage de création d’une dépense saisie manuellement. Recherchez l’événement initial de création de l’enregistrement dans la table des dépenses ou des transactions. Collecte Enregistré directement lorsqu’une transaction par carte est traitée ou qu’un utilisateur crée une nouvelle dépense. Type d’événement explicit
	Dépense soumise	L’employé confirme que toutes les informations nécessaires concernant une dépense sont complètes et la soumet pour approbation. Cette action explicite fait passer la dépense de l’état « draft » ou « needs attention » à l’état « pending approval ».
Pourquoi c’est important Cette activité constitue une étape déterminante 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ù les obtenir Capturé dans l’historique des statuts de l’objet dépense. Cela correspond à l’action de l’utilisateur qui soumet la transaction pour examen. Collecte Enregistré lorsque l’utilisateur clique sur le bouton « Submit », ce qui déclenche un changement de statut. Type d’événement explicit
	Remboursement exécuté	Le paiement du remboursement a été traité avec succès et envoyé à l’employé. Il s’agit généralement de la dernière étape pour l’employé et de la fin du cycle de paiement.
Pourquoi c’est important Il s’agit de l’événement de fin principal du processus de remboursement. La durée entre la soumission et cette étape constitue un KPI important pour la satisfaction des employés et l’efficacité du processus. Où les obtenir Capturé dans les journaux de traitement des paiements ou par une intégration avec le prestataire de paiement. Le statut de la dépense dans Ramp est alors mis à jour vers « Reimbursed » ou « Paid ». Collecte Un événement est enregistré lorsque le système de paiement confirme le transfert des fonds. Type d’événement explicit
	Synchronisée avec le système comptable	Les données de la transaction de dépense ont été enregistrées avec succès dans le système comptable intégré, tel que NetSuite, QuickBooks ou Xero. Cet événement marque la fin de la tenue des comptes dans le processus.
Pourquoi c’est important Il s’agit de la dernière activité du processus de bout en bout. Les retards à ce stade peuvent nuire à l’exactitude des rapports financiers et ralentir la clôture financière. Où les obtenir Enregistré dans un journal d’intégration ou sous la forme d’une mise à jour du statut de l’objet dépense dans Ramp. Recherchez un statut tel que « Synced », « Posted » ou « Exported ». Collecte Une entrée est créée dans le journal par le service d’intégration comptable après la synchronisation réussie des données. Type d’événement explicit
	Approuvée par la finance	L’équipe financière a examiné la dépense et donné son approbation finale. La dépense peut désormais être remboursée et synchronisée avec le système comptable. Cet événement est enregistré à la suite d’une action explicite d’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é permet de comprendre le cycle d’approbation de bout en bout et l’efficacité de l’équipe financière. Où les obtenir Enregistré comme événement dans l’historique d’approbation de la dépense. Recherchez un événement d’approbation associé à un utilisateur du service financier. Collecte Un événement est enregistré lorsqu’un utilisateur disposant des droits financiers effectue l’action « Approve ». Type d’événement explicit
	Contrôle de politique effectué	Le système vérifie automatiquement la dépense au regard des politiques configurées de l’entreprise et signale les violations potentielles. Il s’agit généralement d’un événement généré par le système, peu après la soumission.
Pourquoi c’est important Mesure l’efficacité des contrôles automatisés de Conformité et leur incidence sur le processus. Aide à identifier les violations de politiques fréquentes et les besoins de formation des employés. Où les obtenir Probablement enregistré dans une piste d’audit ou un journal associé à la transaction de dépense. Recherchez les événements système liés à « policy_check » ou « compliance_scan ». Collecte Une entrée est créée dans le journal système après l’exécution du moteur automatisé de contrôle des politiques sur la transaction. Type d’événement explicit
	Dépense renvoyée pour correction	Un approbateur, responsable ou contrôleur financier, a rejeté la dépense et l’a renvoyée à l’employé pour correction. Cet événement est enregistré par un changement de statut vers « Needs Revision » ou « Rejected ».
Pourquoi c’est important Cette activité signale une boucle de reprise dans le processus, ce qui augmente directement le délai de traitement. Le suivi de ces événements permet d’identifier les erreurs fréquentes lors de la soumission et d’améliorer le taux de traitement correct dès le premier passage. Où les obtenir Déduit d’un changement de statut de l’objet dépense vers « Needs Revision » ou un état similaire. L’événement doit être associé à l’approbateur à l’origine de l’action. Collecte Déduit de l’horodatage auquel le statut de la dépense devient « Needs Revision » ou « Rejected ». Type d’événement inferred
	En attente d’examen financier	Une dépense approuvée a été transmise à l’équipe financière ou comptable et attend désormais son examen. Cela se produit généralement pour les dépenses élevées ou celles qui comportent des alertes 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 permet d’évaluer la charge et l’efficacité de l’équipe financière, ainsi que d’identifier les possibilités d’automatisation. Où les obtenir Déduit d’un changement de statut de l’objet dépense vers « Pending Finance Approval » après l’approbation managériale. L’accès à l’historique des statuts de la dépense est nécessaire. Collecte Déduit de l’horodatage auquel le statut de la dépense devient « Pending Finance Review ». Type d’événement inferred
	En attente d’examen par le responsable	La dépense a été soumise et attend désormais l’examen du responsable hiérarchique direct de l’employé. Cet état est déduit lorsque le statut de la dépense devient « Pending Manager Approval » ou une valeur similaire après la soumission.
Pourquoi c’est important Indique le début de l’étape d’approbation managériale. L’analyse du temps passé dans cet état est essentielle pour mesurer et améliorer les délais du cycle d’approbation managériale. Où les obtenir Déduit d’un changement de statut de l’objet dépense vers un état tel que « Pending Approval » et de son affectation à la file d’attente d’un responsable. Le suivi de l’historique des statuts est nécessaire. Collecte Déduit de l’horodatage auquel le statut de la dépense devient « Pending Manager Approval ». Type d’événement inferred
	Justificatif joint	Représente le moment où un justificatif est associé à une dépense, automatiquement par rapprochement OCR ou manuellement par l’utilisateur. Cet événement est enregistré lorsque le fichier du justificatif est correctement lié à l’enregistrement de la transaction.
Pourquoi c’est important Le suivi de cette activité permet d’identifier les retards dus à l’absence de justificatifs. Il s’agit d’une étape importante pour garantir la Conformité et la préparation aux audits. Où les obtenir Enregistré dans l’historique de la dépense ou de la transaction lorsqu’un justificatif est importé ou rapproché. Recherchez un événement de création de pièce jointe ou un indicateur tel que « receipt_attached ». Collecte L’événement est créé lorsque le système associe une image ou un fichier de justificatif à l’enregistrement de la dépense. Type d’événement explicit
	Remboursement planifié	Pour les dépenses personnelles à rembourser, le montant approuvé a été placé dans la file de traitement des paiements. Cet événement indique que la dépense a franchi toutes les étapes d’approbation et peut être payée.
Pourquoi c’est important Cette étape distingue le processus d’approbation de l’exécution du paiement. Elle permet d’isoler les retards liés au traitement des paiements de ceux qui surviennent pendant les approbations. Où les obtenir Probablement déduit du passage du statut de la dépense à « Pending Reimbursement » ou « Ready for Payment » après l’approbation finale. Il peut également s’agir d’un événement explicite lorsque les paiements sont regroupés par lots. Collecte Déduit d’un changement de statut vers « Ready for Payout » ou de la création d’un enregistrement dans une table de lots de paiement. Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment récupérer vos données depuis Ramp

Étapes

Connectez-vous à votre compte Ramp avec des privilèges d’administrateur ou de comptable.
Accédez à la section Transactions dans le menu de gauche. Cette vue contient toutes les dépenses effectuées avec les cartes professionnelles.
Appliquez les filtres souhaités aux données. Au minimum, définissez une période correspondant à la période que vous souhaitez analyser. Vous pouvez également filtrer selon d’autres propriétés, comme le statut, la catégorie ou le service, afin de réduire le périmètre si nécessaire.
Cliquez sur le bouton Export 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.
Accédez ensuite à la section Remboursements dans le menu de gauche. Cette vue contient toutes les dépenses personnelles soumises par les employés.
Appliquez le même filtre de période que celui utilisé pour l’exportation des transactions afin de garantir la cohérence des données.
Cliquez sur le bouton Export et téléchargez les données de remboursement au format CSV. Nommez le 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. Il chargera les deux fichiers, transformera les données en créant une ligne distincte pour chaque événement métier, puis les fusionnera dans un journal d’événements structuré unique.
Le script générera un fichier nommé ramp_event_log.csv. Ce fichier est formaté conformément aux exigences de ProcessMind.
Importez le fichier ramp_event_log.csv dans ProcessMind pour l’analyser.

Configuration

Permissions : vous devez disposer du rôle « Admin » ou « Bookkeeper » dans Ramp pour accéder à l’ensemble des données de transactions et de remboursements et les exporter.
Date Range : pour une première analyse, sélectionnez une période d’au moins 6 à 12 mois afin de couvrir suffisamment de variations du processus. Pour un suivi continu, vous pouvez utiliser une période plus courte et plus récente.
Data Consistency : utilisez exactement la même période et les mêmes filtres pour exporter les fichiers Transactions et Reimbursements, afin de conserver un jeu de données cohérent.
Export Format : sélectionnez toujours le format CSV pour les deux exports, car le script de transformation est conçu pour traiter des fichiers séparés par des virgules.
File Naming : respectez les noms transactions_export.csv et reimbursements_export.csv, ou modifiez les variables de chemin d’accès dans le script de transformation en conséquence.

a Exemple de requête python

import pandas as pd
import numpy as np

class=class="hl-string">"hl-comment"># --- Configuration ---
TRANSACTIONS_FILE = class="hl-string">'transactions_export.csv'
REIMBURSEMENTS_FILE = class="hl-string">'reimbursements_export.csv'
OUTPUT_FILE = class="hl-string">'ramp_event_log.csv'

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

class=class="hl-string">"hl-comment"># --- Main Transformation Logic ---
def transform_to_event_log(transactions_df, reimbursements_df):
    events = []

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

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

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

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

        class=class="hl-string">"hl-comment"># Activity: Expense Incurred
        if pd.notna(row.get(class="hl-string">'ExpenseIncurredTimestamp')):
            events.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Expense Incurred', class="hl-string">'EventTimestamp': row.get(class="hl-string">'ExpenseIncurredTimestamp')})

        class=class="hl-string">"hl-comment"># Activity: Receipt Attached
        if pd.notna(row.get(class="hl-string">'ReceiptAttachedTimestamp')):
            events.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Receipt Attached', class="hl-string">'EventTimestamp': row.get(class="hl-string">'ReceiptAttachedTimestamp')})

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

        class=class="hl-string">"hl-comment"># Activity: Manager Approved
        if pd.notna(row.get(class="hl-string">'ManagerApprovedTimestamp')):
            events.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Manager Approved', class="hl-string">'EventTimestamp': row.get(class="hl-string">'ManagerApprovedTimestamp')})

        class=class="hl-string">"hl-comment"># Activity: Finance Review Pending
        if pd.notna(row.get(class="hl-string">'FinanceReviewPendingTimestamp')):
            events.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Finance Review Pending', class="hl-string">'EventTimestamp': row.get(class="hl-string">'FinanceReviewPendingTimestamp')})

        class=class="hl-string">"hl-comment"># Activity: Finance Approved
        if pd.notna(row.get(class="hl-string">'FinanceApprovedTimestamp')):
            events.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Finance Approved', class="hl-string">'EventTimestamp': row.get(class="hl-string">'FinanceApprovedTimestamp')})

        class=class="hl-string">"hl-comment"># Activity: Synced with Accounting System
        if pd.notna(row.get(class="hl-string">'SyncedTimestamp')):
            events.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Synced with Accounting System', class="hl-string">'EventTimestamp': row.get(class="hl-string">'SyncedTimestamp')})

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

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

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

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

    if not events:
        print(class="hl-string">"Warning: No events were generated. Check the input files and column names.")
        return None

    class=class="hl-string">"hl-comment"># Create final DataFrame
    event_log_df = pd.DataFrame(events)
    event_log_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(event_log_df[class="hl-string">'EventTimestamp'])
    event_log_df.sort_values(by=[class="hl-string">'ExpenseReportId', class="hl-string">'EventTimestamp'], inplace=True)
    
    return event_log_df

class=class="hl-string">"hl-comment"># --- Main execution block ---
if __name__ == class="hl-string">"__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=class="hl-string">'%Y-%m-%dT%H:%M:%S.%fZ')
            print(fclass="hl-string">"Successfully created event log with {len(event_log)} events. Saved to '{OUTPUT_FILE}'.")

Étapes

Prérequis et configuration de l’environnement : vérifiez que Python 3.8 ou une version ultérieure est installé. Installez les bibliothèques Python nécessaires en exécutant pip install requests pandas. Vous devez également disposer d’un accès administrateur à votre instance Ramp pour générer les identifiants d’API.
Générer les identifiants de l’API Ramp : connectez-vous à votre compte Ramp. Ouvrez Settings, puis sélectionnez Developer API dans le menu latéral. Cliquez sur « Create App », donnez un nom à votre application et configurez les portées requises. Vous aurez besoin de transactions:read, reimbursements:read et users:read. Une fois l’application créée, copiez le Client ID et le Client Secret dans un emplacement sécurisé.
Configurer le script Python : créez un nouveau fichier Python, par exemple extract_ramp_log.py. Copiez-y le script Python fourni. Définissez votre Client ID et votre Client Secret comme variables d’environnement ou directement dans le script à des fins de test. Pour des raisons de sécurité, l’utilisation de variables d’environnement est fortement recommandée.
Définir la période d’extraction : dans le script, repérez les variables START_DATE et END_DATE dans le bloc d’exécution main. Modifiez ces dates pour définir la période d’extraction. Pour une première analyse, une période de 3 à 6 mois est recommandée.
Exécuter le script : lancez le script depuis votre terminal à l’aide de 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 de terminaison users, transactions et reimbursements, puis gérera automatiquement la pagination.
Comprendre les appels d’API : le script récupère d’abord toutes les données utilisateurs afin de créer une correspondance entre les identifiants utilisateurs, les noms et les services. Il récupère ensuite tous les remboursements compris dans la période définie. Pour chaque remboursement, il extrait l’historique des approbations et des paiements.
Transformer les données en journal d’événements : la logique principale du script parcourt chaque remboursement et l’historique d’état associé. Elle convertit chaque changement d’état, comme « MANAGER_APPROVAL » ou « FINISHED », en une activité distincte telle que « Manager Review Pending » ou « Reimbursement Executed ». Elle récupère également les données de transaction associées pour créer les événements « Expense Incurred » et « Receipt Attached ».
Enrichir les données : le script enrichit le journal d’événements en ajoutant les informations utilisateur, le service et la catégorie de dépenses pour chaque événement, afin de constituer un jeu de données complet pour l’analyse des processus.
Vérifier le résultat : une fois le script terminé, il génère un fichier nommé ramp_event_log.csv dans le même répertoire. Ouvrez ce fichier CSV dans un tableur pour examiner les données et vérifier que l’extraction s’est déroulée comme prévu.
Préparer l’importation : le fichier CSV généré contient les colonnes requises ExpenseReportId, ActivityName, EventTimestamp ainsi que d’autres attributs recommandés. Il est prêt à être importé directement dans la plateforme ProcessMind.

Configuration

API Credentials : un Client ID et un Client Secret valides sont nécessaires pour l’authentification. Ils sont générés dans le Dashboard Ramp, sous Settings > Developer API.
API Scopes : le script nécessite des autorisations spécifiques pour accéder aux données. Vérifiez que les portées suivantes sont activées pour votre clé d’API : transactions:read (pour les détails des dépenses et des justificatifs), reimbursements:read (pour les statuts de soumission, d’approbation et de paiement) et users:read (pour le nom et le service des collaborateurs).
Date Range : l’extraction est régie par les paramètres START_DATE et END_DATE du script. Il est recommandé de commencer par une période récente, par exemple les 3 à 6 derniers mois, afin de conserver un jeu de données initial facile à gérer. Le filtre s’applique à la date de création du remboursement.
Pagination : le script gère automatiquement la pagination de l’API à l’aide du curseur starting_after fourni par l’API Ramp. Il récupère les enregistrements par lots, jusqu’à 100 par requête, afin de garantir l’extraction de toutes les données comprises dans la période définie.
Rate Limiting : l’API Ramp est soumise à des limites de débit, généralement de 600 requêtes par minute. Le script fourni est généralement efficace, mais pour des jeux de données très volumineux, vous devrez peut-être introduire de courtes pauses entre les appels d’API si des erreurs de limite de débit apparaissent.

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

Vérifiez que votre abonnement Ramp inclut l’intégration native à l’entrepôt de données et qu’un administrateur peut configurer la destination. Sélectionnez l’entrepôt cible pris en charge, comme Snowflake ou BigQuery, puis configurez l’accès conformément aux normes de sécurité de votre organisation. Les chemins de menu et les objets de destination exacts dépendent de votre configuration Ramp. Utilisez donc [Configure based on your system].
Configurez la destination de l’entrepôt, la base de données ou le projet, le schéma ou le jeu de données, la région, les identifiants et le périmètre de synchronisation. Notez les noms des tables et des colonnes répliquées affichés par Ramp. Ne présumez pas des noms de tables, car ils varient selon l’intégration et la configuration du compte.
Identifiez les données répliquées relatives aux rapports de dépenses, aux transactions, aux justificatifs, aux approbations, aux politiques, aux remboursements et à la synchronisation comptable. Faites correspondre chaque source aux champs requis pour le journal d’événements. Si un événement du cycle de vie requis n’est pas représenté explicitement, identifiez l’historique des statuts ou les données d’audit qui l’enregistrent.
Définissez la période d’extraction, de préférence trois à six mois, à l’aide de [Start date] et [End date]. N’appliquez des filtres d’entreprise ou d’organisation que lorsque le champ source correspondant est disponible. Conservez le fuseau horaire source ou convertissez tous les horodatages vers un fuseau horaire commun documenté.
Créez une vue ou une requête d’entrepôt qui normalise les champs sources en ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag et RevisionReason. Remplacez chaque espace réservé entre crochets pour les tables et les colonnes de la requête fournie par les noms issus de votre schéma répliqué.
Extrayez chaque activité du cycle de vie sous la forme d’une ligne d’événement explicite. La requête ci-dessous contient un bloc SELECT complet pour chacune des 12 activités requises. Elle ne déduit pas les événements à partir d’enregistrements sans lien. Pour les activités fondées sur un statut, utilisez l’historique des statuts ou la table d’événements source, et non le seul statut actuel du rapport, afin de conserver les transitions historiques.
Validez les identifiants, les horodatages, les libellés d’activité, le traitement des doublons et la gestion des valeurs nulles. Vérifiez que chaque événement est associé au bon ExpenseReportId et que les événements répétés sont conservés lorsque la source enregistre plusieurs occurrences légitimes.
Exportez le résultat au format CSV ou dans un autre format tabulaire pris en charge par ProcessMind. Incluez exactement les noms de colonnes requis ExpenseReportId, ActivityName et EventTimestamp, ajoutez les attributs recommandés lorsqu’ils sont disponibles, puis importez le fichier en utilisant Expense Report ID comme identifiant de cas. ProcessMind lit le journal d’événements tel quel. Ne vous attendez donc pas à ce qu’il reconstitue les activités manquantes.

Configuration

Destination de l’intégration : configurez l’intégration native de Ramp avec un entrepôt Snowflake ou BigQuery, en utilisant [Configure based on your system] pour la configuration exacte de votre compte.
Objets sources : utilisez les objets répliqués relatifs aux rapports de dépenses, aux transactions, aux justificatifs, aux approbations, aux politiques, aux remboursements et à la synchronisation comptable, exposés dans votre entrepôt. Remplacez les espaces réservés [Your table name] et [Your column name] par les noms vérifiés dans l’intégration.
Période : commencez par trois à six mois de données. N’élargissez la période qu’après avoir validé le coût de l’entrepôt, la durée des requêtes, le volume d’événements et les limites d’importation de ProcessMind.
Filtrage des dates : filtrez sur l’horodatage de l’événement plutôt que sur la seule date de création du rapport lorsque l’objectif est de capturer toutes les activités sur la période.
Filtres organisationnels : appliquez les filtres Company Code, entité, service, programme de cartes ou autres uniquement lorsque ces champs existent dans les données répliquées. Utilisez [Company filter] lorsqu’une restriction propre à une entreprise est nécessaire.
Historique des activités : privilégiez les enregistrements d’audit ou d’historique des statuts immuables. Les seules tables d’état courant peuvent ne pas conserver l’historique des ajouts de justificatifs, des soumissions, des approbations, des révisions, des remboursements ou de la synchronisation comptable.
Gestion des horodatages : standardisez les horodatages sur un seul fuseau horaire et documentez si les valeurs sources sont en UTC ou en heure locale. Conservez la précision de la source lorsqu’elle est disponible.
Accès requis : un administrateur peut avoir besoin des autorisations nécessaires pour configurer l’intégration, créer ou interroger des objets de l’entrepôt et accéder aux données de dépenses, d’approbation, de remboursement et de comptabilité.
Licences et disponibilité : la disponibilité de la réplication vers l’entrepôt, des données d’audit historiques, des données de remboursement et des données de synchronisation comptable dépend de l’offre Ramp, des modules activés, de la configuration de l’intégration et de la politique de conservation.
Performance : limitez rapidement la période, sélectionnez uniquement les colonnes nécessaires, filtrez par organisation lorsque cela est pertinent et matérialisez une vue ou une table intermédiaire normalisée pour les jeux de données volumineux. Partitionnez ou regroupez les données selon les fonctionnalités prises en charge par l’entrepôt cible.
Traitement incrémentiel : pour les chargements récurrents, utilisez un point de reprise fondé sur le plus grand EventTimestamp traité, avec une petite fenêtre de chevauchement. Ne dédupliquez les données qu’à l’aide d’un identifiant d’événement source vérifié, car la suppression d’événements répétés peut modifier le comportement du processus.

a Exemple de requête python

import os
import pandas as pd
from sqlalchemy import create_engine, text

CONNECTION_STRING = os.getenv(class="hl-string">"WAREHOUSE_CONNECTION_STRING", class="hl-string">"[Connection string]")
START_DATE = class="hl-string">"[Start date]"
END_DATE = class="hl-string">"[End date]"
COMPANY_FILTER = class="hl-string">"[Company filter]"

engine = create_engine(CONNECTION_STRING)

sql = text(class="hl-string">"""
WITH
expense_incurred AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Expense Incurred' AS ActivityName,
        [Expense incurred timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your expense incurred table]
    WHERE [Expense incurred timestamp column] >= :start_date
      AND [Expense incurred timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
receipt_attached AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Receipt Attached' AS ActivityName,
        [Receipt attached timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your receipt attachment table]
    WHERE [Receipt attached timestamp column] >= :start_date
      AND [Receipt attached timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
expense_submitted AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Expense Submitted' AS ActivityName,
        [Submission timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your expense submission table]
    WHERE [Submission timestamp column] >= :start_date
      AND [Submission timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
policy_check_performed AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Policy Check Performed' AS ActivityName,
        [Policy check timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your policy check table]
    WHERE [Policy check timestamp column] >= :start_date
      AND [Policy check timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
manager_review_pending AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Manager Review Pending' AS ActivityName,
        [Manager pending timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your expense status history table]
    WHERE [Status column] = 'Pending Manager Approval'
      AND [Manager pending timestamp column] >= :start_date
      AND [Manager pending timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
manager_approved AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Manager Approved' AS ActivityName,
        [Manager approval timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your manager approval table]
    WHERE [Manager approval timestamp column] >= :start_date
      AND [Manager approval timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
finance_review_pending AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Finance Review Pending' AS ActivityName,
        [Finance pending timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your expense status history table]
    WHERE [Status column] = 'Pending Finance Approval'
      AND [Finance pending timestamp column] >= :start_date
      AND [Finance pending timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
finance_approved AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Finance Approved' AS ActivityName,
        [Finance approval timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your finance approval table]
    WHERE [Finance approval timestamp column] >= :start_date
      AND [Finance approval timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
expense_sent_back AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Expense Sent Back for Revision' AS ActivityName,
        [Revision timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        [Revision reason column] AS RevisionReason
    FROM [Your expense status history table]
    WHERE [Status column] IN ('Needs Revision', 'Rejected')
      AND [Revision timestamp column] >= :start_date
      AND [Revision timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
reimbursement_scheduled AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Reimbursement Scheduled' AS ActivityName,
        [Reimbursement scheduled timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your reimbursement schedule table]
    WHERE [Reimbursement scheduled timestamp column] >= :start_date
      AND [Reimbursement scheduled timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
reimbursement_executed AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Reimbursement Executed' AS ActivityName,
        [Reimbursement executed timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your reimbursement payment table]
    WHERE [Reimbursement executed timestamp column] >= :start_date
      AND [Reimbursement executed timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
synced_with_accounting AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Synced with Accounting System' AS ActivityName,
        [Accounting sync timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your accounting synchronization table]
    WHERE [Accounting sync timestamp column] >= :start_date
      AND [Accounting sync timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
)
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM expense_incurred
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM receipt_attached
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM expense_submitted
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM policy_check_performed
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM manager_review_pending
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM manager_approved
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM finance_review_pending
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM finance_approved
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM expense_sent_back
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM reimbursement_scheduled
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM reimbursement_executed
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM synced_with_accounting
ORDER BY ExpenseReportId, EventTimestamp, ActivityName
""")

with engine.connect() as connection:
    event_log = pd.read_sql(
        sql,
        connection,
        params={
            class="hl-string">"start_date": START_DATE,
            class="hl-string">"end_date": END_DATE,
            class="hl-string">"company_filter": COMPANY_FILTER
        }
    )

event_log[class="hl-string">"EventTimestamp"] = pd.to_datetime(event_log[class="hl-string">"EventTimestamp"], errors=class="hl-string">"coerce", utc=True)
event_log = event_log[event_log[class="hl-string">"ExpenseReportId"].notna() & event_log[class="hl-string">"EventTimestamp"].notna()].copy()
event_log.to_csv(class="hl-string">"ramp_expense_event_log.csv", index=False)
print(event_log.head())
print(event_log.groupby(class="hl-string">"ActivityName", dropna=False).size())

Prêt à commencer ?

Utilisez ce modèle pour transformer votre processus de gestion des dépenses, améliorer son efficacité et accélérer les approbations. Commencez dès aujourd’hui à optimiser vos opérations.

Retour au guide d’amélioration Télécharger le modèle

Gagnez en efficacité : optimisez dès aujourd’hui la gestion de vos dépenses dans Ramp

Repérez les inefficacités, accélérez les approbations et réduisez de 30 % le délai de traitement.

Démarrer l’essai gratuit

Aucune carte bancaire requise, configuration en quelques minutes.

Votre modèle de données de gestion des dépenses

Votre modèle de données de gestion des dépenses

Attributs de la gestion des dépenses

Activités de gestion des dépenses

Guides d’extraction

Export CSV intégré des transactions et des remboursements dans Ramp

Étapes

Configuration

a Exemple de requête python

Extraction avec un script Python via l’API Developer de Ramp

Étapes

Configuration

a Exemple de requête python

Synchronisation avec l’entrepôt de données Ramp (Snowflake/BigQuery)

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Gagnez en efficacité : optimisez dès aujourd’hui la gestion de vos dépenses dans Ramp

Votre modèle de données de gestion des dépenses

Votre modèle de données de gestion des dépenses

Attributs de la gestion des dépenses

Activités de gestion des dépenses

Guides d’extraction

Export CSV intégré des transactions et des remboursements dans Ramp

Étapes

Configuration

a Exemple de requête python

Extraction avec un script Python via l’API Developer de Ramp

Étapes

Configuration

a Exemple de requête python

Synchronisation avec l’entrepôt de données Ramp (Snowflake/BigQuery)

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Gagnez en efficacité : optimisez dès aujourd’hui la gestion de vos dépenses dans Ramp

Nous attachons de l’importance à votre confidentialité