> Amélioration Continue des Processusus > Gestion des dépenses > Ramp > Template de données

Votre modèle de données de 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 de Gestion des Dépenses

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

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

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

Télécharger le modèle

Attributs de gestion des dépenses

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

3 Obligatoire 6 Recommandé 10 Facultatif

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

Obligatoire Recommandé Facultatif

Activités de gestion des dépenses

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

5 Recommandé 7 Facultatif

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

Recommandé Facultatif

Guides d'extraction

Comment obtenir vos données de Ramp

Étapes

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

Configuration

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

a Exemple de requête config

import pandas as pd
import numpy as np

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Étapes

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

Configuration

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

a Exemple de requête python

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

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

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

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

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

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

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

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

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

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

    event_log = []

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

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

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

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

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

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

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

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

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

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

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

Étapes

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

Configuration

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

a Exemple de requête config

import pandas as pd
import numpy as np

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Votre modèle de données de Gestion des Dépenses

Votre modèle de données de Gestion des Dépenses

Attributs de gestion des dépenses

Activités de gestion des dépenses

Guides d'extraction

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

Étapes

Configuration

a Exemple de requête config

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

Étapes

Configuration

a Exemple de requête python

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

Étapes

Configuration

a Exemple de requête config

Prêt(e) à démarrer ?

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

Votre modèle de données de Gestion des Dépenses

Votre modèle de données de Gestion des Dépenses

Attributs de gestion des dépenses

Activités de gestion des dépenses

Guides d'extraction

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

Étapes

Configuration

a Exemple de requête config

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

Étapes

Configuration

a Exemple de requête python

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

Étapes

Configuration

a Exemple de requête config

Nous respectons votre vie privée

Prêt(e) à démarrer ?

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