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

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

Ramp

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

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

Ce modèle vous guide dans la collecte des 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 réunir les informations nécessaires à la découverte et à l’amélioration de vos processus.

Attributs recommandés à collecter
Activités clés à suivre
Conseils d’extraction pour Ramp

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs de 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	Date et heure exactes auxquelles l’activité a eu lieu.
Description Chaque activité du processus est associée à un horodatage qui indique quand elle a eu lieu. Ces données temporelles servent à classer les événements par ordre chronologique et constituent la base de toutes les analyses de durée. En Process Mining, les horodatages permettent de calculer les temps de cycle entre les activités, de mesurer la durée totale d’un cas et de repérer les retards. Ces informations sont essentielles au suivi des performances et à l’identification des possibilités d’amélioration du processus. Pourquoi est-ce important ? Cet attribut établit l’ordre chronologique des événements. Il est indispensable au calcul des durées et à l’analyse des performances. Où trouver ces données Ces informations figurent généralement avec les activités ou les statuts 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	Identifiant unique de chaque note de frais, utilisé comme identifiant principal du cas dans le processus.
Description L’identifiant de la note de frais regroupe tous les événements et activités liés à une même soumission de dépenses. Il permet de suivre chronologiquement une demande de remboursement, de sa saisie initiale à son paiement final. En Process Mining, cet attribut est essentiel pour reconstituer le parcours de bout en bout de chaque note de frais. Utilisé comme identifiant de cas, il permet de calculer précisément les temps de cycle, de repérer les goulots d’étranglement et de visualiser les différents parcours des notes de frais dans le processus d’approbation. Pourquoi est-ce important ? Cet attribut fondamental relie toutes les activités associées à une même instance du processus et rend possible l’analyse de bout en bout. Où trouver ces données Cet identifiant doit figurer 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	Nom de l’événement ou de la tâche 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, par exemple « Dépense soumise », « Dépense approuvée par le responsable » ou « Remboursement effectué ». Ces activités constituent les nœuds de la carte du processus et permettent de visualiser et d’analyser son déroulement. L’analyse des activités permet de repérer les étapes les plus fréquentes, les goulots d’étranglement et les différences entre les flux de travail. Elle est essentielle pour comprendre l’enchaînement des opérations et mesurer les résultats à chaque étape. Pourquoi est-ce important ? Cet attribut définit les étapes de la carte du processus et permet de visualiser et d’analyser son déroulement, du début à la fin. Où trouver ces données Cet attribut est généralement extrait des journaux d’événements ou des enregistrements de changement de statut associés à chaque note de frais dans Ramp. Exemples Dépense soumiseDépense approuvée par le responsableEn attente de l’examen par l’équipe financièreRemboursement effectué
	Catégorie de dépense ExpenseCategory	Catégorie attribuée à une dépense, par exemple « Déplacements », « Logiciels » ou « Repas ».
Description Cet attribut classe les dépenses dans des catégories prédéfinies afin de faciliter le suivi et le contrôle des dépenses de l’entreprise. Une note de frais peut regrouper des dépenses de plusieurs catégories. L’analyse par catégorie de dépense est essentielle au Dashboard « Analyse des catégories de dépenses ». Elle aide les équipes financières à comprendre où va l’argent, à suivre le respect des budgets et à repérer les tendances ou les anomalies au fil du temps. Pourquoi est-ce important ? Cet attribut permet d’analyser les dépenses en détail, de repérer les principaux postes de coûts et de trouver des possibilités d’optimisation budgétaire. Où trouver ces données Cette information figure généralement au niveau de chaque ligne de dépense dans la note de frais Ramp. Pour certaines analyses, il peut être nécessaire d’agréger les données au niveau de la note. Exemples Billets d’avionRepas et divertissementsAbonnement logicielFournitures de bureau
	Indicateur d’infraction aux règles PolicyViolationFlag	Indique si la note de frais a été signalée pour une infraction aux règles.
Description Cet attribut booléen prend la valeur « true » lorsque les contrôles automatisés du système détectent une infraction potentielle aux règles de dépenses de l’entreprise, par exemple le dépassement d’un plafond ou la soumission d’une dépense en double. Cet indicateur est essentiel au Dashboard « Détection des infractions aux règles » et à l’indicateur associé. Il permet d’évaluer l’efficacité des contrôles et de repérer les manquements fréquents, afin d’orienter la mise à jour des règles ou la formation des employés. Pourquoi est-ce important ? Cet attribut mesure directement le respect des règles de dépenses. Il aide à repérer et à réduire les dépenses non conformes ainsi que les risques associés. Où trouver ces données Il s’agit probablement d’un indicateur généré par le système dans Ramp, déclenché par les contrôles automatisés effectués lors de la soumission ou de l’approbation. Exemples truefalse
	Montant total de la note ReportTotalAmount	Montant total de la note de frais.
Description Cet attribut correspond à la somme de toutes les dépenses figurant sur une même note. Il s’agit d’un indicateur financier important pour comprendre les habitudes de dépenses. Dans l’analyse des processus, le montant de la note permet de segmenter les cas et de vérifier si les notes d’un montant élevé suivent un parcours d’approbation différent ou prennent plus de temps à traiter. Il est essentiel aux Dashboards d’analyse des dépenses et à la recherche de possibilités de réduction des coûts. Pourquoi est-ce important ? Cet attribut apporte un axe financier important à l’analyse. Il permet de classer les notes selon leur montant et de suivre les dépenses globales. Où trouver ces données Il s’agit d’un champ principal de l’objet note de frais dans Ramp. Exemples 150.752500.0089.99
	Motif de correction RevisionReason	Motif indiqué lorsqu’une note de frais est renvoyée à l’employé pour correction.
Description Lorsqu’un approbateur rejette ou renvoie une note de frais, il en indique généralement le motif. Cet attribut enregistre ce motif, par exemple « Justificatif manquant », « Catégorie incorrecte » ou « Dépense non conforme aux règles ». Ces informations sont très utiles au Dashboard « Taux et motifs de correction des notes de frais ». L’analyse des motifs de reprise les plus fréquents permet aux organisations de repérer les problèmes récurrents dans le processus de soumission et de mettre en place des formations ciblées ou des améliorations du système pour réduire les erreurs. Pourquoi est-ce important ? Cet attribut met en évidence les causes des reprises et permet de prendre des mesures ciblées pour améliorer la qualité des notes dès leur première soumission. Où trouver ces données Ces données sont enregistrées dans les commentaires ou les détails du rejet lorsque l’activité « Dépense renvoyée pour correction » se produit dans Ramp. Exemples Justificatif détaillé manquantDépense supérieure au plafond autoriséCatégorie de dépense incorrecteTransaction en double
	Nom de l’utilisateur UserName	Nom ou identifiant de l’utilisateur qui a effectué l’activité, qu’il s’agisse de l’employé ayant soumis la dépense ou de l’approbateur.
Description Cet attribut identifie la personne responsable d’un événement 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 de travail, de repérer les personnes les plus performantes et d’identifier celles qui pourraient avoir besoin d’une formation complémentaire. Cet attribut est essentiel aux Dashboards consacrés aux performances d’approbation et à la gestion des ressources. Pourquoi est-ce important ? Cet attribut associe les activités du processus à des personnes précises. Il permet d’analyser les performances à l’échelle des ressources et de repérer les besoins de formation. Où trouver ces données Dans Ramp, les informations sur l’utilisateur figurent généralement dans la piste d’audit ou l’historique des transactions de chaque note de frais. Exemples Alice JohnsonBob SmithCharlie BrownAutomatisation du système
	Service de l’employé EmployeeDepartment	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é qui a soumis la dépense, par exemple « Ventes », « Ingénierie » ou « Marketing ». Il s’agit d’un axe d’analyse important, qui permet de filtrer et de comparer les performances du processus entre les différentes parties de l’organisation. Il peut révéler des écarts entre les services concernant les délais d’approbation, les taux de correction et le respect des règles, et ainsi orienter les initiatives d’amélioration. Pourquoi est-ce important ? Cet attribut permet de comparer les indicateurs du processus entre les unités opérationnelles et de repérer les écarts d’efficacité, de conformité et de dépenses. Où trouver ces données 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 des finances FinanceApprover	Utilisateur de l’équipe financière ayant approuvé le rapport de dépenses.
Description Dans les flux de travail qui comportent une étape de vérification par l’équipe financière, cet attribut désigne la personne ou l’équipe du service financier qui a donné l’approbation finale. Il alimente le Dashboard « Efficacité de la vérification financière », qui permet d’analyser les performances par personne ou par équipe. Il aide à repérer les goulots d’étranglement, à évaluer la répartition de la charge de travail et à mesurer l’efficacité de cette étape de vérification. Pourquoi est-ce important ? Cet attribut permet d’analyser en détail les performances de l’étape de vérification financière et d’optimiser un point de contrôle important du processus. Où trouver ces données Cette information serait consignée dans l’historique d’approbation du rapport de dépenses dans Ramp, au cours de l’étape de vérification financière. Exemples Équipe financière ADavid LeeBot d’automatisation des finances
	Avec reprise IsRework	Indicateur calculé précisant si un rapport de dépenses a été renvoyé pour correction au moins une fois.
Description Cet attribut booléen est calculé en vérifiant si l’activité « Rapport de dépenses renvoyé pour correction » a eu lieu pour un cas donné. Il prend la valeur true pour tout rapport ayant fait l’objet d’au moins un cycle de correction. Cet indicateur simplifie le calcul du KPI « Taux de correction des rapports de dépenses » et permet de comparer facilement les rapports approuvés dès la première soumission à ceux qui ont nécessité des reprises. L’analyse de ces deux groupes peut révéler les conséquences des corrections en matière de délais et de coûts. Pourquoi est-ce important ? Cet attribut permet de segmenter facilement le processus pour analyser les reprises et mesurer la fréquence et les conséquences des rapports renvoyés pour correction. Où trouver ces données Ce champ est calculé lors de la transformation des données, en vérifiant si le cas comporte une activité de correction. Exemples truefalse
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière actualisation des données depuis le système source.
Description Cet attribut indique la date et l’heure de la dernière extraction des données. Il renseigne sur leur fraîcheur au moment de l’analyse. Pour interpréter correctement les résultats, il est important de connaître la date des données. Cet attribut permet de vérifier si les informations consultées sont à jour. Pourquoi est-ce important ? Il indique si les données sont récentes, afin que les analyses reposent sur des informations à jour et pertinentes. Où trouver ces données 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	Horodatage indiquant la fin d’une activité ayant une durée.
Description De nombreuses activités sont instantanées, mais certaines, comme « Vérification de la politique effectuée », peuvent avoir une durée mesurable. Cet attribut enregistre l’heure de fin de ces activités et complète StartTime. La présence des heures de début et de fin permet de calculer précisément la durée de traitement des activités. Cette information est essentielle pour des indicateurs tels que « Durée moyenne de vérification de la politique » et pour déterminer le temps nécessaire à l’exécution de tâches automatisées ou manuelles dans le processus global. Pourquoi est-ce important ? Cet attribut permet de calculer précisément la durée de chaque activité et de repérer les étapes inefficaces du processus. Où trouver ces données Pour les activités ayant une durée, cette information serait enregistrée dans les données d’événement 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	Mode utilisé pour effectuer le remboursement, par exemple un virement ACH ou un virement bancaire.
Description Cet attribut indique le canal de paiement utilisé pour rembourser le salarié. Les délais de traitement et les coûts peuvent varier selon le mode choisi. L’analyse des remboursements par mode de paiement permet de repérer les canaux les plus efficaces. Le Dashboard « Performance des modes de remboursement » s’appuie sur ces données pour comparer les temps de cycle et la fiabilité, et ainsi orienter l’optimisation des stratégies de paiement. Pourquoi est-ce important ? Cet attribut permet de comparer les performances des différents canaux de paiement et d’optimiser les délais et la fiabilité. Où trouver ces données Ces informations devraient figurer dans les enregistrements de paiement ou de remboursement de Ramp. Exemples Virement ACHCrédit sur carte d’entrepriseVirement direct
	Mode de soumission SubmissionMethod	Canal utilisé pour soumettre le rapport de dépenses, par exemple une application mobile ou un portail Web.
Description Cet attribut indique comment le salarié a soumis son rapport de dépenses. Les méthodes courantes comprennent l’application mobile, le navigateur Web sur ordinateur et le transfert par e-mail. L’analyse du mode de soumission peut éclairer les habitudes des utilisateurs et l’adoption des technologies. Par exemple, un taux élevé de corrections pour les rapports soumis par un canal donné peut signaler des problèmes d’ergonomie dans son interface. Pourquoi est-ce important ? Cet attribut renseigne sur les habitudes des utilisateurs et peut aider à déterminer si certains canaux de soumission sont associés à davantage d’erreurs ou de retards. Où trouver ces données Ces informations peuvent figurer 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	Nombre total d’étapes d’approbation formelles suivies par un rapport de dépenses.
Description Cette métrique calculée compte les activités d’approbation distinctes, telles que « Approbation du responsable » et « Approbation des finances », enregistrées pour un même rapport de dépenses. Elle permet de mesurer la complexité du flux de travail d’approbation. Cet attribut sert au KPI « Nombre moyen d’étapes d’approbation par rapport » et au Dashboard « Parcours d’approbation simples des dépenses ». En analysant ce nombre, notamment en fonction du montant ou de la catégorie du rapport, les organisations peuvent déterminer si des dépenses simples et de faible montant sont soumises à un processus d’approbation trop complexe. Pourquoi est-ce important ? Cet attribut mesure la complexité du flux de travail et aide à repérer les possibilités de simplification, en particulier pour les rapports à faible risque. Où trouver ces données Cette valeur est calculée en comptant les occurrences d’activités d’approbation précises pour chaque cas dans le journal d’événements. Exemples 123
	Responsable approbateur ApprovingManager	Nom du responsable qui a effectué l’étape d’approbation.
Description Cet attribut identifie le responsable chargé d’examiner et d’approuver la note de frais d’un employé. Il est distinct de l’utilisateur qui a soumis la note. Le suivi du responsable approbateur est essentiel au Dashboard « Temps de cycle d’approbation par responsable ». Il permet d’analyser la charge d’approbation et les performances, et de repérer les responsables qui approuvent rapidement les demandes ainsi que ceux qui créent des goulots d’étranglement. Ces informations peuvent aider à mieux répartir la charge de travail ou à fournir une assistance supplémentaire. Pourquoi est-ce important ? Cet attribut permet d’analyser les performances de chaque approbateur et de repérer les goulots d’étranglement dans le flux de travail d’approbation. Où trouver ces données Ces informations font partie des données du flux de travail d’approbation dans Ramp. Elles sont enregistrées lorsqu’un responsable intervient sur un rapport. Exemples Jane DoeJohn MillerSusan Chen
	Résultat de l’audit AuditOutcome	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 « Approuvé », « Partiellement refusé » ou « Informations complémentaires requises ». Ces données sont au cœur du Dashboard « Performance des audits de dépenses ». Elles permettent d’évaluer l’efficacité du processus d’audit, de suivre la fréquence des différents résultats et de comprendre les conséquences financières des constats d’audit. Pourquoi est-ce important ? Cet attribut mesure l’efficacité et les résultats du processus d’audit, et met en évidence les problèmes de conformité et les faiblesses des contrôles. Où trouver ces données Ces informations seraient enregistrées dans le module d’audit de Ramp ou dans un système intégré utilisé pour réaliser des audits détaillés des dépenses. Exemples RéussiRéussi avec remarquesRejetéTransmis à un niveau supérieur
	Système source SourceSystem	Indique l’application source à partir de laquelle les données ont été extraites.
Description Cet attribut indique le système de référence des données du processus, ici Ramp. Il est utile lorsque les données proviennent de plusieurs systèmes, car il permet d’en retracer clairement l’origine. Il permet de filtrer les données selon leur source et peut servir à leur validation ainsi qu’à leur gouvernance. Pourquoi est-ce important ? Cet attribut précise l’origine des données, une information importante pour leur gouvernance et l’intégration de données provenant de plusieurs systèmes. Où trouver ces données 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 à consigner dans votre journal d’événements pour découvrir le processus et mesurer ses performances avec précision.

5 Recommandé 7 Facultatif

	Activité	Description
	Dépense approuvée par le responsable	Le responsable a examiné et approuvé la dépense. Celle-ci peut passer à l’étape suivante, par exemple l’examen par l’équipe financière ou le remboursement. L’événement correspond à une action explicite de l’utilisateur.
Pourquoi est-ce important ? Cette étape importante confirme que le premier niveau d’approbation est terminé. Son analyse permet d’étudier les flux de travail d’approbation et de repérer les goulots d’étranglement. Où trouver ces données L’événement est enregistré dans l’historique des approbations de la dépense lorsque le responsable clique sur « Approve ». Le journal d’événements doit contenir l’identifiant de la personne ayant approuvé la dépense et un horodatage. Données à recueillir L’événement est enregistré lorsqu’un utilisateur disposant des droits d’un responsable clique sur « Approve ». Type d’événement explicit
	Dépense engagée	Cet événement marque la création d’une dépense. Il est généralement déclenché automatiquement lors de l’utilisation d’une carte d’entreprise ou lorsqu’un employé saisit manuellement une dépense payée de sa poche. Il est habituellement enregistré à partir des flux de données de transaction ou des actions effectuées dans l’interface.
Pourquoi est-ce important ? Il s’agit du principal événement de début du cycle de vie d’une dépense. Le temps écoulé depuis cet événement permet d’évaluer les délais de soumission et la durée globale du processus. Où trouver ces données Cet événement est généré à partir des journaux de transactions par carte de Ramp ou de l’horodatage de création d’une dépense saisie manuellement. Recherchez l’événement de création initiale dans la table des dépenses ou des transactions. Données à recueillir L’événement est enregistré directement lors du traitement d’une transaction par carte ou de la création d’une dépense par un utilisateur. Type d’événement explicit
	Dépense soumise	L’employé confirme que toutes les informations nécessaires concernant la dépense sont complètes, puis la soumet pour approbation. Cette action explicite fait passer la dépense de l’état « brouillon » ou « à traiter » à l’état « en attente d’approbation ».
Pourquoi est-ce important ? Cette activité marque une étape importante : elle lance officiellement le cycle d’approbation et de remboursement. Elle sert de point de départ pour mesurer les délais de service liés à l’approbation et au remboursement. Où trouver ces données L’événement est extrait de l’historique des statuts de la dépense. Il correspond à l’action de l’utilisateur qui soumet la transaction pour examen. Données à recueillir L’événement est enregistré lorsque l’utilisateur clique sur le bouton « Submit », ce qui entraîne un changement de statut. Type d’événement explicit
	Remboursement effectué	Le remboursement a été traité et versé à 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 est-ce important ? Il s’agit du principal événement de fin du processus de remboursement. Le délai entre la soumission et cette étape est un indicateur essentiel de la satisfaction des employés et de l’efficacité du processus. Où trouver ces données L’événement est extrait des journaux de traitement des paiements ou d’une intégration avec le prestataire de paiement. Dans Ramp, le statut de la dépense passe à « Reimbursed » ou « Paid ». Données à recueillir Un événement est enregistré lorsque le système de paiement confirme que le transfert a bien été effectué. Type d’événement explicit
	Synchronisée avec le système comptable	Les données de la transaction ont été enregistrées dans le système comptable intégré, par exemple NetSuite, QuickBooks ou Xero. Cet événement marque la fin de la tenue des comptes liée au processus.
Pourquoi est-ce important ? Il s’agit de la dernière activité du processus de bout en bout. Les retards à cette étape peuvent nuire à la précision des rapports financiers et ralentir la clôture des comptes. Où trouver ces données L’événement est enregistré dans un journal d’intégration ou dans une mise à jour du statut de la dépense dans Ramp. Recherchez un statut tel que « Synced », « Posted » ou « Exported ». Données à recueillir Le service d’intégration comptable ajoute une entrée au journal une fois la synchronisation des données effectuée. Type d’événement explicit
	Contrôle des règles effectué	Le système vérifie automatiquement la dépense au regard des règles configurées par l’entreprise et signale toute infraction potentielle. Cet événement, généralement généré par le système, survient peu après la soumission.
Pourquoi est-ce important ? Cette mesure évalue l’efficacité des contrôles automatisés de conformité et leur incidence sur le processus. Elle aide à repérer les infractions fréquentes et les sujets sur lesquels former les employés. Où trouver ces données L’événement figure probablement dans une piste d’audit ou un journal associé à la transaction. Recherchez les événements système liés à « policy_check » ou « compliance_scan ». Données à recueillir Une entrée est ajoutée au journal système après l’exécution du moteur automatisé de contrôle des règles sur la transaction. Type d’événement explicit
	Dépense approuvée par l’équipe financière	L’équipe financière a examiné et approuvé définitivement la dépense. Celle-ci peut être remboursée et synchronisée avec le système comptable. L’événement correspond à une action explicite d’un membre de l’équipe financière.
Pourquoi est-ce important ? Cette étape constitue le dernier contrôle avant le paiement. Son analyse permet de comprendre le cycle d’approbation de bout en bout et d’évaluer l’efficacité de l’équipe financière. Où trouver ces données L’événement est enregistré dans l’historique des approbations de la dépense. Recherchez un événement d’approbation associé à un utilisateur du service financier. Données à recueillir L’événement est enregistré lorsqu’un utilisateur disposant des droits de l’équipe financière clique sur « Approve ». Type d’événement explicit
	Dépense renvoyée pour correction	Un approbateur, responsable ou membre de l’équipe financière, a rejeté la dépense et l’a renvoyée à l’employé pour correction. L’événement correspond au passage du statut à « Needs Revision » ou « Rejected ».
Pourquoi est-ce important ? Cette activité marque une boucle de reprise dans le processus, qui allonge directement le temps de cycle. Le suivi de ces événements permet de repérer les erreurs fréquentes dans les demandes et d’améliorer leur qualité dès la première soumission. Où trouver ces données Cet état est déduit du passage du statut de la dépense à « Needs Revision » ou à une valeur similaire. L’événement doit être associé à l’approbateur à l’origine de l’action. Données à recueillir L’événement est déterminé à partir de l’horodatage auquel le statut de la dépense passe à « Needs Revision » ou « Rejected ». Type d’événement inferred
	En attente de l’examen du responsable	La dépense a été soumise et attend maintenant l’examen du responsable direct de l’employé. Cet état est déduit du passage du statut de la dépense à « Pending Manager Approval » ou à une valeur similaire après la soumission.
Pourquoi est-ce important ? Cet événement marque le début de l’étape d’approbation par le responsable. L’analyse du temps passé dans cet état est essentielle pour mesurer et réduire les délais d’approbation. Où trouver ces données Cet état est déduit du changement de statut de la dépense vers une valeur telle que « Pending Approval » et de son affectation à la file d’attente d’un responsable. Il faut pour cela suivre l’historique des statuts. Données à recueillir L’événement est déterminé à partir de l’horodatage auquel le statut de la dépense passe à « Pending Manager Approval ». Type d’événement inferred
	En attente de l’examen par l’équipe financière	Une dépense approuvée a été transmise à l’équipe financière ou comptable et attend maintenant son examen. Cela concerne généralement les dépenses élevées ou celles qui ont été signalées lors d’un contrôle des règles. L’activité est déduite d’un changement de statut.
Pourquoi est-ce important ? Cet événement marque le début de l’examen par l’équipe financière. La durée de cette étape permet d’évaluer la charge de travail et l’efficacité de l’équipe, ainsi que de repérer les possibilités d’automatisation. Où trouver ces données Cet état est déduit du passage du statut de la dépense à « Pending Finance Approval » après l’approbation du responsable. Il faut pour cela accéder à l’historique des statuts de la dépense. Données à recueillir L’événement est déterminé à partir de l’horodatage auquel le statut de la dépense passe à « Pending Finance Review ». Type d’événement inferred
	Justificatif joint	Cet événement correspond au moment où un justificatif est associé à une dépense, automatiquement par rapprochement OCR ou manuellement par l’utilisateur. Il est enregistré lorsque le fichier du justificatif est correctement lié à la transaction.
Pourquoi est-ce important ? Le suivi de cette activité permet de repérer les retards dus à des justificatifs manquants. Cette étape est importante pour assurer la conformité et préparer les audits. Où trouver ces données L’événement est 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 signalant « receipt_attached ». Données à recueillir L’événement est créé lorsque le système associe une image ou un fichier de justificatif à la dépense. Type d’événement explicit
	Remboursement programmé	Pour les dépenses payées de leur poche, le montant approuvé a été placé dans la file d’attente de traitement des paiements. Cet événement indique que la dépense a reçu toutes les approbations et peut être remboursée.
Pourquoi est-ce important ? Cette étape marque la transition entre le processus d’approbation et le traitement du paiement. Elle permet de distinguer les retards liés au paiement de ceux qui surviennent pendant les approbations. Où trouver ces données L’événement est probablement déduit du passage du statut de la dépense à « Pending Reimbursement » ou « Ready for Payment » après l’approbation finale. Il peut aussi s’agir d’un événement explicite lorsque les paiements sont regroupés en lots. Données à recueillir L’événement est déterminé à partir du passage du statut à « 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 les droits d’administrateur ou de comptable.
Dans le menu de gauche, ouvrez la section Transactions. Elle contient toutes les dépenses effectuées avec les cartes d’entreprise.
Appliquez les filtres souhaités. Au minimum, définissez une Plage de dates correspondant à la période à analyser. Vous pouvez aussi filtrer par statut, catégorie ou service pour réduire le périmètre, si nécessaire.
Cliquez sur le bouton Exporter, en haut à droite de la liste des transactions.
Dans la fenêtre d’export, sélectionnez Transactions comme type d’export et CSV comme format. Téléchargez le fichier et nommez-le transactions_export.csv.
Ouvrez ensuite la section Remboursements dans le menu de gauche. Elle contient toutes les dépenses personnelles soumises par les salariés.
Appliquez la même plage de dates que pour l’export des transactions afin de garantir la cohérence des données.
Cliquez sur Exporter 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 réunira dans un journal d’événements structuré.
Le script générera un fichier nommé ramp_event_log.csv, au format requis par ProcessMind.
Importez le fichier ramp_event_log.csv dans ProcessMind pour l’analyser.

Configuration

Autorisations : vous devez disposer des rôles « Admin » ou « Bookkeeper » dans Ramp pour accéder à l’ensemble des données de transactions et de remboursements et les exporter.
Plage de dates : pour une première analyse, choisissez une période d’au moins 6 à 12 mois afin de couvrir suffisamment de variantes du processus. Pour le suivi régulier, une période plus courte et plus récente peut convenir.
Cohérence des données : utilisez exactement la même plage de dates et les mêmes filtres pour exporter les fichiers Transactions et Remboursements afin de conserver un jeu de données cohérent.
Format d’export : choisissez toujours le format CSV pour les deux exports, car le script de transformation traite des fichiers séparés par des virgules.
Noms de fichiers : conservez les noms transactions_export.csv et reimbursements_export.csv, ou modifiez en conséquence les variables de chemin d’accès dans le script de transformation.

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 des identifiants API.
Générez les identifiants API Ramp : connectez-vous à votre compte Ramp. Ouvrez Settings, puis sélectionnez Developer API dans le menu latéral. Cliquez sur « Create App », nommez votre application et configurez les autorisations requises. Vous aurez besoin de transactions:read, reimbursements:read et users:read. Une fois l’application créée, copiez en lieu sûr le Client ID et le Client Secret.
Configurez le script Python : créez un fichier Python, par exemple extract_ramp_log.py, puis copiez-y le script fourni. Pour les tests, définissez votre Client ID et votre Client Secret comme variables d’environnement ou directement dans le script. Pour des raisons de sécurité, il est vivement recommandé d’utiliser des variables d’environnement.
Définissez la plage de dates d’extraction : dans le bloc d’exécution main du script, repérez les variables START_DATE et END_DATE. Modifiez ces dates pour définir la période d’extraction des données. Pour une première analyse, une période de 3 à 6 mois est recommandée.
Exécutez le script : lancez-le depuis votre terminal avec 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 des utilisateurs, des transactions et des remboursements, et gérera automatiquement la pagination.
Comprenez les appels API : le script récupère d’abord les données de tous les utilisateurs afin d’associer les identifiants utilisateur aux noms et aux services. Il récupère ensuite tous les remboursements de la période définie. Pour chaque remboursement, il extrait l’historique des approbations et des paiements.
Transformez les données en journal d’événements : le script parcourt chaque remboursement et l’historique des états qui lui est associé. Il convertit chaque changement d’état, comme « MANAGER_APPROVAL » ou « FINISHED », en une activité distincte, par exemple « Vérification du responsable en attente » ou « Remboursement effectué ». Il récupère également les données de transaction associées pour créer les événements « Dépense engagée » et « Reçu joint ».
Enrichissez les données : le script complète le journal d’événements avec les informations sur les utilisateurs, les services et les catégories de dépenses, afin de constituer un jeu de données complet pour l’analyse des processus.
Vérifiez le résultat : à la fin de l’exécution, un fichier nommé ramp_event_log.csv est créé dans le même répertoire. Ouvrez-le dans un tableur pour examiner les données et vérifier que l’extraction s’est déroulée comme prévu.
Préparez l’importation : le fichier CSV généré contient les colonnes requises, notamment ExpenseReportId, ActivityName et EventTimestamp, ainsi que d’autres attributs recommandés. Vous pouvez l’importer directement dans la plateforme ProcessMind.

Configuration

Identifiants API : un Client ID et un Client Secret valides sont nécessaires pour l’authentification. Vous pouvez les générer dans le Dashboard Ramp, sous Settings > Developer API.
Autorisations API : le script nécessite des autorisations précises pour accéder aux données. Vérifiez que les autorisations suivantes sont activées pour votre clé API : transactions:read (détails des dépenses et des reçus), reimbursements:read (soumission, approbation et état du paiement) et users:read (nom et service des salariés).
Plage de dates : l’extraction est définie par les paramètres START_DATE et END_DATE du script. Pour commencer, il est recommandé de choisir une période récente, par exemple les 3 à 6 derniers mois, afin de limiter la taille du premier jeu de données. 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 d’inclure toutes les données de la période choisie.
Limitation du débit : l’API Ramp impose des limites de débit, généralement de 600 requêtes par minute. Le script fourni est conçu pour être efficace, mais pour les très grands jeux de données, vous devrez peut-être insérer de courtes pauses entre les appels API si vous rencontrez des erreurs liées à ces limites.

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 à un entrepôt de données et qu’un administrateur peut configurer la destination. Sélectionnez un entrepôt pris en charge, comme Snowflake ou BigQuery, puis configurez les accès selon les normes de sécurité de votre organisation. Les menus et les objets de destination varient selon votre configuration Ramp : utilisez [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.
Repérez les données répliquées relatives aux rapports de dépenses, aux transactions, aux reçus, aux approbations, aux politiques, aux remboursements et à la synchronisation comptable. Associez chaque source aux champs requis pour le journal d’événements. Si un événement nécessaire du cycle de vie n’est pas représenté explicitement, repérez l’historique des états ou les données d’audit qui le consignent.
Définissez la période d’extraction, de préférence de trois à six mois, à l’aide de [Start date] et [End date]. Appliquez des filtres par entreprise ou par organisation uniquement si le champ correspondant est disponible dans la source. Conservez le fuseau horaire de la source ou convertissez tous les horodatages dans un fuseau horaire commun documenté.
Créez une vue ou une requête dans l’entrepôt qui normalise les champs source en ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag et RevisionReason. Remplacez chaque espace réservé entre crochets dans la requête fournie par les noms correspondant à 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 d’événements à partir d’enregistrements sans rapport. Pour les activités fondées sur un état, utilisez l’historique des états ou la table d’événements source, et non le seul état actuel du rapport, afin de conserver les transitions passées.
Vérifiez les identifiants, les horodatages, les libellés d’activité, le traitement des doublons et des valeurs nulles. Confirmez 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, ainsi que les attributs recommandés lorsqu’ils sont disponibles. Importez le fichier en utilisant Expense Report ID comme identifiant de cas. ProcessMind lit le journal d’événements tel quel : ne comptez pas sur la plateforme pour déduire les activités manquantes.

Configuration

Destination de l’intégration : configurez l’intégration native de Ramp à Snowflake ou BigQuery. Pour connaître la configuration exacte de votre compte, utilisez [Configure based on your system].
Objets source : utilisez les objets répliqués relatifs aux rapports de dépenses, aux transactions, aux reçus, aux approbations, aux politiques, aux remboursements et à la synchronisation comptable, disponibles 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.
Plage de dates : commencez par trois à six mois de données. N’élargissez la période qu’après avoir vérifié 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 par date : filtrez sur l’horodatage de l’événement, plutôt que sur la seule date de création du rapport, si vous souhaitez inclure toutes les activités survenues pendant la période.
Filtres organisationnels : appliquez des filtres par code d’entreprise, entité, service, programme de cartes ou autre critère uniquement si les champs correspondants 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 données d’audit immuables ou l’historique des états. Les tables décrivant uniquement l’état actuel peuvent ne pas conserver l’historique des pièces jointes, des soumissions, des approbations, des corrections, des remboursements ou de la synchronisation comptable.
Gestion des horodatages : harmonisez les horodatages dans un même fuseau horaire et indiquez si les valeurs source sont en UTC ou en heure locale. Conservez la précision de la source lorsqu’elle est disponible.
Accès requis : un administrateur peut devoir disposer 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é.
Licence et disponibilité : la disponibilité de la réplication dans 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.
Performances : limitez la période dès le départ, sélectionnez uniquement les colonnes nécessaires, filtrez par organisation lorsque cela convient et, pour les grands jeux de données, matérialisez une vue ou une table intermédiaire normalisée. 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 comme point de reprise le plus grand EventTimestamp traité, auquel vous ajouterez une courte période 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.

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 ?

Appuyez-vous sur ce modèle pour transformer votre processus de gestion des dépenses, gagner en 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 des dépenses dans Ramp

Repérez les inefficacités, simplifiez les approbations et réduisez le temps de cycle de 30 %.

Démarrez l’essai gratuit

Aucune carte bancaire requise. Configuration en quelques minutes.

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

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

Attributs de 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

Exemple de requête python

Extraction à l’aide d’un script Python via l’API développeur de Ramp

Étapes

Configuration

Exemple de requête python

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

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

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

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

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

Attributs de 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

Exemple de requête python

Extraction à l’aide d’un script Python via l’API développeur de Ramp

Étapes

Configuration

Exemple de requête python

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

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

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

Prêt à commencer ?

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