> Kontinuierliche Prozessoptimierung > Spesenmanagement > Ramp > Datenvorlage

Ihr Template für Spesenmanagement-Daten

Ramp

Spesenmanagement-Attribute (19) Spesenmanagement-Aktivitäten (12) Extraktionsanleitungen (3)

Ihr Template für Spesenmanagement-Daten

Diese Datenvorlage bietet einen klaren Leitfaden zur Sammlung der notwendigen Daten, um Ihren Spesenmanagementprozess zu analysierenn und zu optimieren. Es umreißt wesentliche Attribute, wichtige zu verfolgende Aktivitäten und praktische Anleitungen zur Datenextraktion aus Ramp. Verwenden Sie diese Ressource, um sicherzustellen, dass Sie alle Informationen für eine aufschlussreiche Prozessentdeckung und -verbesserung sammeln.

Empfohlene Attribute zur Erfassung
Wichtige Aktivitäten für das Tracking
Extraktionsanleitung für Ramp

Neu bei Event-Logs? Erfahren Sie wie Sie ein Process-Mining-Event-Log erstellen.

Vorlage herunterladen

Spesenmanagement-Attribute

Dies sind die relevanten Datenfelder, die in Ihrem Event Log für eine vollständige Analyse Ihres Spesenmanagementprozesses enthalten sein sollten.

3 Erforderlich 6 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des spezifischen Ereignisse oder den Antrag bearbeitet.er Aufgabe, die zu einem bestimmten Zeitpunkt innerhalb des Spesenmanagementprozesses aufgetreten ist.
Beschreibung Dieses Attribut beschreibt einen einzelnen Schritt im Lebenszyklus der Spesenabrechnung, wie z.B. 'Ausgabe eingereicht', 'Manager genehmigt' oder 'Erstattung ausgeführt'. Diese Aktivitäten bilden die Knoten im Prozessmodell und ermöglichen die Visualisierung und Analyse des Prozessflusses. Die Analyse von Aktivitäten hilft zu identifizieren, welche Schritte am häufigsten sind, wo Engpässe auftreten und wie sich verschiedene Workflows unterscheiden. Es ist eine Kernkomponente zum Verständnis der Abfolge der Operations und zur Messung der Leistungsfähigkeit in jeder Phase. Bedeutung Es definiert die Schritte in der Prozesskarte und ermöglicht die Visualisierung und Analyse des Prozessflusses von Anfang bis Ende. Datenquelle Dies wird in der Regel aus Event-Logs oder StatusänderungsDatensätzen abgeleitet, die mit jeder Spesenabrechnung in Ramp verbunden sind. Beispiele Spese eingereichtDurch Manager freigegebenFinanzprüfung ausstehende Zahlungen identifizieren.endErstattung ausgeführt
	Ereignis-Zeitstempel EventTimestamp	Das genaue Datum und die Uhrzeit, zu der den Antrag bearbeitet.ie Aktivität stattgefunden hat.
Beschreibung Jede `Activity` im Prozess hat einen entsprechenden `Zeitstempel`, der aufzeichnet, wann sie stattgefunden hat. Diese temporalen `data` werden verwendet, um `Events` chronologisch zu ordnen und bilden die Grundlage für alle zeitbezogenen Analysen. Im `Process Mining` werden `Zeitstempel` verwendet, um `Durchlaufzeits` zwischen `activities` zu berechnen, die Gesamtdauer eines `case` zu messen und Verzögerungen zu identifizieren. Diese Informationen sind wichtig für das `Leistungsfähigkeit Monitoring` und die Identifizierung von Möglichkeiten zur Prozessoptimierung. Bedeutung Dieses Attribut liefert die chronologische Reihenfolge der Ereignisse und ist wichtig für alle Dauerberechnungen und Leistungsfähigkeit-Analysen. Datenquelle Diese Information findet sich in der Regel zusammen mit den Aktivitäts- oder Statusaufzeichnungen in den Event-Logs oder TransaktionsDaten von Ramp. Beispiele 2023-10-26T10:00:00Z2023-10-26T14:30:00Z2023-10-27T09:00:00Z
	Spesenabrechnungs-ID ExpenseReportId	Der eindeutige Identifikator für jede Spesenabrechnung, der als primärer Case-ID für den Prozess dient.
Beschreibung Die Spesenabrechnungs-ID gruppiert alle Ereignisse und Aktivitäten, die mit einer einzigen Speseneinreichung verbunden sind. Sie ermöglicht eine vollständige, chronologische Nachverfolgung eines Spesenantrags von der Ersterfassung bis zur endgültigen Zahlung. Im Process Mining ist dieses Attribut unerlässlich, um den End-to-End-Prozess jeder Spesenabrechnung zu rekonstruieren. Durch die Verwendung als Case-ID können Analysen präzise Durchlaufzeiten berechnen, Engpässe identifizieren und die verschiedenen Wege visualisieren, die Berichte durch den Genehmigungsprozess nehmen. Bedeutung Dies ist das grundlegende Attribut, das alle zugehörigen Aktivitäten zu einer einzigen Prozessinstanz verknüpft und so eine End-to-End-Analyse ermöglicht. Datenquelle Dieser Identifikator sollte in der Haupt-Spesenabrechnung oder Transaktionstabelle innerhalb von Ramp verfügbar sein. Beispiele ER-2023-08-1123ER-2023-09-4591ER-2023-10-0024
	Benutzername UserName	Der Name oder den Antrag bearbeitet.ie ID des Benutzers, der den Antrag bearbeitet.ie Aktivität durchgeführt hat, einschließlich des Mitarbeiters, der den Antrag bearbeitet.ie Ausgabe einreicht, oder den Antrag bearbeitet.es Genehmigers.
Beschreibung Dieses Attribut identifiziert die für ein bestimmtes Event im Prozess verantwortliche Person, z.B. das Einreichen, Genehmigen oder Überprüfen einer Spesenabrechnung. Dies kann der Name eines Mitarbeiters oder eine eindeutige Benutzer-ID sein. Die Analyse nach Benutzer hilft, die Arbeitslastverteilung zu verstehen, Top-Performer zu identifizieren und Personen zu finden, die möglicherweise zusätzliche Schulungen benötigen. Es ist maßgeblich für Dashboards zur Genehmigungs-Leistungsfähigkeit und zum Ressourcenmanagement. Bedeutung Es ordnet Prozess `activities` bestimmten Personen zu, ermöglicht eine `Leistungsfähigkeit Analysis` auf Ressourcenebene und identifiziert Schulungsbedarfe. Datenquelle BenutzerHinweisrmationen werden in der Regel im Prüfpfad oder in der Transaktionshistorie für jede Spesenabrechnung in Ramp protokolliert. Beispiele Alice JohnsonBob SmithCharlie BrownSystem Automatisierung
	Gesamtbetrag des Berichts ReportTotalAmount	Der Gesamtbetrag des Spesenberichts.
Beschreibung Dieses Attribut repräsentiert die Summe aller in einem einzigen Bericht enthaltenen Ausgaben. Es ist eine wichtige Finanzkennzahl zum Verständnis von Ausgabenmustern. In der Prozessanalyse kann der Berichtsbetrag verwendet werden, um Fälle zu segmentieren und zu untersuchen, ob hochpreisige Berichte unterschiedliche Genehmigungspfade verfolgen oder länger dauern. Es ist die Basis für Spend Analysis Dashboards und zur Identifizierung von Kosteneinsparungspotenzialen. Bedeutung Es bietet eine wichtige finanzielle Dimension für die Analyse, die die Segmentierung von Berichten nach Wert und die Verfolgung der Gesamtausgaben ermöglicht. Datenquelle Dies ist ein primäres Feld im Spesenabrechnungsobjekt in Ramp. Beispiele 150.752500.0089.99
	Grund für die Überarbeitung RevisionReason	Der Grund, der angegeben wird, wenn eine Spesenabrechnung zur Überarbeitung an den Mitarbeiter zurückgesandt wird.
Beschreibung Wenn ein Genehmiger eine Spesenabrechnung ablehnt oder zur Überarbeitung zurücksendet, gibt er in der Regel einen Grund an. Dieses Attribut erfasst diesen Grund, wie z.B. 'Beleg fehlt', 'Falsche Kategorie' oder 'Außerhalb der Richtlinie'. Diese Information ist von besonders wertvoll für das Dashboard 'Spesenüberarbeitungsrate & Ursachen'. Durch die Analyse der häufigsten Gründe für Nacharbeit können Organisationen systemische Probleme im Einreichungsprozess identifizieren und gezielte Schulungen oder Systemverbesserungen implementieren, um Fehler zu reduzieren. Bedeutung Es bietet direkten Einblick in die Grundursachen von Nacharbeit und ermöglicht gezielte Maßnahmen zur Verbesserung der Qualität der Ersteinreichung. Datenquelle Diese Daten würden in den Kommentaren oder Ablehnungsdetails erfasst, wenn die Aktivität 'Spesen zur Überarbeitung zurückgesandt' in Ramp auftritt. Beispiele Fehlender den Antrag bearbeitet.etaillierter BelegSpese überschreitet RichtliniengrenzeFalsche Spesenkategorie ausgewähltDoppelte Transaktion
	Mitarbeiterabteilung EmployeeDepartment	Die Abteilung des Mitarbeiters, der den Antrag bearbeitet.en Spesenbericht eingereicht hat.
Beschreibung Dieses Attribut gibt die Geschäftseinheit oder Abteilung an, zu der den Antrag bearbeitet.er speseneinreichende Mitarbeiter gehört, wie z.B. 'Vertrieb', 'Entwicklung' oder 'Marketing'. Dies ist eine kritische Dimension für die Analyse, da sie das Filtern und Vergleichen der Prozess-Leistungsfähigkeit über verschiedene Teile der Organisation hinweg ermöglicht. Sie kann Variationen bei Genehmigungszeiten, Überarbeitungsraten und Richtlinienkonformität zwischen Abteilungen aufzeigen und so gezielte Verbesserungsinitiativen unterstützen. Bedeutung Es ermöglicht den Vergleich von Prozessmetriken über verschiedene Geschäftsbereiche hinweg und hebt Abweichungen in Effizienz, `Compliance` und Ausgaben hervor. Datenquelle Diese Information ist wahrscheinlich mit dem Benutzerprofil des Mitarbeiters in Ramp oder einem integrierten HR-System verknüpft. Beispiele VertriebMarketingEngineeringFinanzen
	Richtlinienverstoß-Kennzeichnung PolicyViolationFlag	Ein Kennzeichen, das anzeigt, ob der Spesenbericht wegen eines Richtlinienverstoßes markiert wurde.
Beschreibung Dieses boolesche Attribut wird auf 'Ja' gesetzt, wenn die automatisierten Systemprüfungen einen potenziellen Verstoß gegen die Unternehmensspesenrichtlinien erkennen, wie z.B. die Überschreitung eines Ausgabenlimits oder den Antrag bearbeitet.ie Einreichung einer doppelten Ausgabe. Dieses Flag ist maßgeblich für das Dashboard 'Erkennung von Richtlinienverstößen' und den zugehörigen KPI. Es hilft, die Wirksamkeit der Richtlinienkontrollen zu messen und gängige Bereiche der Nichteinhaltung zu identifizieren, was Richtlinienaktualisierungen oder Mitarbeiterschulungen beeinflussen kann. Bedeutung Es misst direkt die Richtlinien-`Compliance` und hilft, nicht `compliant`e Ausgaben und damit verbundene Risiken zu identifizieren und zu reduzieren. Datenquelle Dies ist wahrscheinlich ein systemgeneriertes Flag innerhalb von Ramp, ausgelöst durch automatisierte Richtlinienprüfungen während des Einreichungs- oder Genehmigungsprozesses. Beispiele JaNein
	Spesenkategorie ExpenseCategory	Die einer Ausgabe zugewiesene Kategorie, wie z.B. 'Reise', 'Software' oder 'Bewirtung'.
Beschreibung Dieses Attribut klassifiziert Ausgaben in vordefinierte Kategorien, was bei der Verfolgung und Kontrolle der Unternehmensausgaben hilft. Eine einzige Spesenabrechnung kann Posten aus mehreren Kategorien enthalten. Die Analyse nach Spesenkategorie ist unerlässlich für das Dashboard 'Ausgabenkategorie-Analyse'. Es hilft Finanzteams zu verstehen, wo Geld ausgegeben wird, die Budgeteinhaltung zu überwachen und Trends oder Anomalien bei den Ausgaben über die Zeit zu identifizieren. Bedeutung Es ermöglicht eine detaillierte Ausgabenanalyse, die hilft, die wichtigsten Kostentreiber und Möglichkeiten zur Budgetoptimierung zu identifizieren. Datenquelle Dies ist in der Regel ein Detail auf Positionsebene auf der Spesenabrechnung in Ramp. Daten müssen möglicherweise auf Berichtsebene für einige Analysen aggregiert werden. Beispiele FlugkostenBewirtung und VerpflegungSoftware-AbonnementnnementBürobedarf
	Anzahl der Genehmigungsschritte ApprovalStepCount	Die Gesamtzahl der formalen Genehmigungsschritte, die eine Spesenabrechnung durchlaufen hat.
Beschreibung Diese berechnete Metrik zählt die Anzahl der unterschiedlichen Genehmigungsaktivitäten, wie z.B. 'Manager genehmigt' und 'Finanzabteilung genehmigt', die für eine einzelne Spesenabrechnung aufgetreten sind. Sie hilft, die Komplexität des Genehmigungs-Workflows zu quantifizieren. Dieses Attribut wird für den KPI 'Durchschnittliche Genehmigungsschritte pro Bericht' und das Dashboard 'Einfache Genehmigungspfade für Spesen' verwendet. Durch die Analyse dieser Zählung, insbesondere in Bezug auf den Wert oder den Antrag bearbeitet.ie Kategorie des Berichts, können Organisationen feststellen, ob einfache, geringwertige Ausgaben übermäßig komplexen Genehmigungsprozessen unterliegen. Bedeutung Es quantifiziert die `Workflow`-Komplexität und hilft, Möglichkeiten zur Vereinfachung zu identifizieren, insbesondere für risikoarme Berichte. Datenquelle Dies wird berechnet, indem die Vorkommen spezifischer genehmigungsbezogener Aktivitäten innerhalb jedes Case im Event Log gezählt werden. Beispiele 123
	Auditergebnis AuditOutcome	Das Ergebnis einer internen oder externen Prüfung der Spesenabrechnung.
Beschreibung Für Spesenberichte, die einer formalen Prüfung (`Audit`) unterzogen werden, zeichnet dieses `Attribute` das Endergebnis auf, wie z. B. „Genehmigt“, „Teilweise abgelehnt“ oder „Weitere Informationen erforderlich“. Diese `data` sind zentral für das `Dashboard` „Expense Audit Leistungsfähigkeit“. Sie helfen bei der Bewertung der Effektivität des `Audit`-Prozesses, der Verfolgung der Häufigkeit verschiedener Resultate und dem Verständnis der finanziellen Auswirkungen von `Audit`-Erkenntnissen. Bedeutung Es misst die Effektivität und Resultate des `Audit`-Prozesses und liefert `insights` in `Compliance`- und Kontrollschwächen. Datenquelle Dies würde im Audit-Modul von Ramp oder einem integrierten System erfasst, falls eines für detaillierte Spesenprüfungen verwendet wird. Beispiele BestandenMit Anmerkungen bestandenAbgelehntEskaliert
	Einreichungsmethode SubmissionMethod	Der Kanal, über den die Spesenabrechnung eingereicht wurde, z.B. mobile App oder Webportal.
Beschreibung Dieses Attribut gibt an, wie der Mitarbeiter seine Spesenabrechnung eingereicht hat. Gängige Methoden sind die Nutzung einer mobilen Anwendung, eines Desktop-Webbrowsers oder den Antrag bearbeitet.ie E-Mail-Weiterleitung. Die Analyse der Einreichungsmethode kann Einblicke in das Benutzerverhalten und die Technologieakzeptanz geben. Beispielsweise könnte eine hohe Überarbeitungsrate bei Berichten, die über einen bestimmten Kanal eingereicht wurden, auf Usability-Probleme mit der Benutzeroberfläche dieses Kanals hinweisen. Bedeutung Es bietet Kontext zum `user`-Verhalten und kann helfen zu identifizieren, ob bestimmte Einreichungskanäle mit höheren Fehlerraten oder Verzögerungen verbunden sind. Datenquelle Diese Information kann in den MetaDaten des Einreichungs-Ereignisse in den System Logs von Ramp erfasst werden. Beispiele Mobile AppWeb-PortalE-Mail
	Endzeit des Ereignisse EventEndTime	Der Zeitstempel, der anzeigt, wann eine Aktivität mit einer Dauer abgeschlossen wurde.
Beschreibung Während viele Aktivitäten augenblicklich sind, können einige, wie 'Richtlinienprüfung durchgeführt', eine messbare Dauer haben. Dieses Attribut erfasst die Endzeit solcher Aktivitäten und ergänzt die Startzeit. Das Vorhandensein von Start- und Endzeit ermöglicht die präzise Berechnung der Aktivitätsbearbeitungszeiten. Dies ist wichtig für KPIs wie 'Durchschnittliche Dauer der Richtlinienprüfung' und zur genauen Identifizierung, wie lange spezifische automatisierte oder manuelle Aufgaben innerhalb des Gesamtprozesses zur Fertigstellung benötigen. Bedeutung Es ermöglicht die präzise Berechnung individueller `Aktivität` Dauern, was wichtig ist, um ineffiziente Prozessschritte zu identifizieren. Datenquelle Für `activities` mit einer Dauer würde dies in den `Event-Daten` von Ramp `logged`. Für sofortige `Events` kann es dasselbe wie die Startzeit sein. Beispiele 2023-10-26T10:00:05Z2023-10-26T14:35:10Z2023-10-27T09:10:00Z
	Erstattungsmethode ReimbursementMethod	Die Methode zur Ausführung der Erstattungszahlung, wie z.B. ACH oder Überweisung.
Beschreibung Dieses Attribut spezifiziert den Zahlungskanal, über den der Mitarbeiter erstattet wurde. Verschiedene Methoden können unterschiedliche Bearbeitungszeiten und Kosten mit sich bringen. Die Analyse der Erstattungs-Leistungsfähigkeit nach Methode hilft, die effizientesten Zahlungskanäle zu identifizieren. Das Dashboard 'Erstattungsmethoden-Leistungsfähigkeit' verwendet diese Daten, um Durchlaufzeiten und Zuverlässigkeit zu vergleichen, was potenziell zur Optimierung von Zahlungsstrategien führt. Bedeutung Es ermöglicht einen Leistungsvergleich zwischen verschiedenen Zahlungskanälen, um die Geschwindigkeit und Zuverlässigkeit zu optimieren. Datenquelle Diese Information sollte in den Zahlungs- oder Erstattungsaufzeichnungen innerhalb von Ramp verfügbar sein. Beispiele ACH-ÜberweisungGuthaben auf FirmenkreditkarteDirekteinzahlung
	Finanzgenehmiger FinanceApprover	Der Benutzer aus dem Finanzteam, der den Antrag bearbeitet.ie Spesenabrechnung genehmigt hat.
Beschreibung Für `Workflows`, die einen Finanzprüfungsschritt umfassen, identifiziert dieses `Attribute` die spezifische Person oder den Antrag bearbeitet.as Team innerhalb der Finanzabteilung, das die endgültige Genehmigung durchgeführt hat. Dieses `Attribute` unterstützt das `Dashboard` „Finance Review Efficiency“, indem es die Analyse der Leistung auf individueller oder Teamebene ermöglicht. Es hilft, `Engpässe` zu identifizieren, die Arbeitslastverteilung zu bewerten und die Effektivität der Finanzprüfungsphase zu messen. Bedeutung Es ermöglicht eine detaillierte `Leistungsfähigkeit Analysis` des Finanzprüfungsschritts, wodurch ein kritischer Kontrollpunkt im Prozess optimiert werden kann. Datenquelle Dies würde in der Genehmigungshistorie der Spesenabrechnung in Ramp während der Finanzprüfungsphase erfasst werden. Beispiele Finanzteam ADavid LeeFinanzautomatisierungs-`Bot`
	Genehmigender Manager ApprovingManager	Der Name des Managers, der den Antrag bearbeitet.en Genehmigungsschritt durchgeführt hat.
Beschreibung Dieses Attribut identifiziert den Manager, der für die Überprüfung und Genehmigung der Spesenabrechnung eines Mitarbeiters zuständig ist. Es unterscheidet sich vom Benutzer, der den Antrag bearbeitet.en Bericht eingereicht hat. Die Verfolgung des genehmigenden Managers ist wichtig für das Dashboard 'Manager Genehmigungs-Durchlaufzeit'. Es ermöglicht die Analyse der Genehmigungslasten und der Leistungsfähigkeit und hebt Manager hervor, die schnell genehmigen, gegenüber denen, die Engpässe darstellen. Dies kann helfen, Arbeitslasten auszugleichen oder zusätzliche Unterstützung bereitzustellen. Bedeutung Es ermöglicht die `Leistungsfähigkeit Analysis` einzelner Genehmiger und hilft, `Engpässe` im Genehmigungs-`workflow` zu identifizieren und zu beheben. Datenquelle Diese Information ist Teil der Genehmigungs-Workflow-Daten in Ramp und wird protokolliert, wenn ein Manager Maßnahmen an einem Bericht vornimmt. Beispiele Jane DoeJohn MillerSusan Chen
	Ist Nacharbeit IsRework	Ein berechnetes Kennzeichen, das anzeigt, ob ein Spesenbericht mindestens einmal zur Überarbeitung zurückgeschickt wurde.
Beschreibung Dieses boolesche Attribut wird abgeleitet, indem geprüft wird, ob die Aktivität 'Spesen zur Überarbeitung zurückgesandt' für einen bestimmten Case aufgetreten ist. Es wird auf 'Ja' gesetzt für jeden Bericht, der mindestens einen Überarbeitungszyklus durchlaufen hat. Dieses Flag vereinfacht die Berechnung des KPI 'Überarbeitungsrate von Spesenabrechnungen' und ermöglicht ein einfaches Filtern und Vergleichen zwischen Berichten, die beim ersten Durchlauf genehmigt wurden, und solchen, die eine Nacharbeit erforderten. Die Analyse dieser beiden Gruppen kann den Zeit- und Kostenaufwand von Überarbeitungen aufzeigen. Bedeutung Es segmentiert den Prozess einfach für die Nacharbeitsanalyse und hilft, die Häufigkeit und Auswirkungen von Berichten zu quantifizieren, die zur Korrektur zurückgeschickt werden. Datenquelle Dies ist ein berechnetes Feld, das während der Datentransformation abgeleitet wird, indem auf die Existenz einer Überarbeitungsaktivität innerhalb des Case geprüft wird. Beispiele JaNein
	Letzte Datenaktualisierung LastDataUpdate	Der Zeitstempel, der den Antrag bearbeitet.en letzten Zeitpunkt angibt, zu dem die Daten aus dem Quellsystem aktualisiert wurden.
Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der aktuellsten Datenextraktion. Es bietet Kontext zur Aktualität der analysierten Daten. In jeder Analyse ist die Kenntnis der Aktualität der Daten wichtig für die korrekte Interpretation der Resultate. Dieses Attribut hilft Benutzern zu verstehen, ob sie aktuelle Informationen betrachten. Bedeutung Es Hinweisrmiert `users` über die Aktualität der `data` und stellt sicher, dass Analysen auf aktuellen und relevanten Informationen basieren. Datenquelle Dieser Zeitstempel wird während des Datenextraktionsprozesses generiert und hinzugefügt. Beispiele 2023-11-01T06:00:00Z
	Quellsystem SourceSystem	Identifiziert die Quellanwendung, aus der den Antrag bearbeitet.ie `data` extrahiert wurden.
Beschreibung Dieses Attribut spezifiziert das führende System für die ProzessDaten, welches in diesem Fall Ramp ist. Es ist nützlich in Umgebungen, in denen Daten aus mehreren Systemen gemischt werden könnten, um eine klare Datenherkunft zu sicherstellen. Für die Analyse hilft es, Daten aus einer spezifischen Quelle zu filtern und kann für Datenvalidierungs- und Governance-Zwecke verwendet werden. Bedeutung Es bietet Kontext zum Ursprung der `data`, was für die `Data Governance` und bei der Integration von `data` aus mehreren Systemen wichtig ist. Datenquelle Dies ist in der Regel ein statischer Wert ('Ramp'), der während des Datenextraktions- und Transformationsprozesses hinzugefügt wird. Beispiele Ramp

Erforderlich Empfohlen Optional

Spesenmanagement-Aktivitäten

Dies sind die zentralen Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten: für eine präzise Prozessanalyse (Discovery) und eine leistungsstarke Leistungsfähigkeit-Messung.

5 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Durch Manager freigegeben	Der Manager hat die Ausgabe geprüft und genehmigt, wodurch sie zum nächsten Schritt, z.B. zur Finanzprüfung oder Erstattung, weitergeleitet wird. Dies wird durch eine explizite Benutzeraktion erfasst.
Bedeutung Dies ist ein wichtiger Meilenstein, der den Antrag bearbeitet.en erfolgreichen Abschluss der ersten Genehmigungsebene anzeigt. Es ist maßgeblich für die Analyse von Genehmigungs-Workflows und die Identifizierung von Engpässen. Datenquelle Als Event in der Genehmigungshistorie der Ausgabe erfasst, wenn der Manager auf 'Genehmigen' klickt. Der Event Log sollte die ID des Genehmigers und einen Zeitstempel enthalten. Erfassen Ein `Event` wird beim 'Genehmigen' durch einen `user` mit Managerberechtigungen `logged`. Ereignistyp explicit
	Erstattung ausgeführt	Die Erstattungszahlung wurde erfolgreich verarbeitet und an den Mitarbeiter gesendet. Dies ist in der Regel der letzte Schritt für den Mitarbeiter und markiert das Ende des Zahlungszyklus.
Bedeutung Dies ist das primäre End-Event für den Erstattungsprozess. Die Dauer von der Einreichung bis zu diesem Punkt ist ein kritischer KPI für die Mitarbeiterzufriedenheit und Prozesseffizienz. Datenquelle Erfasst aus Zahlungsabwicklungs-`Logs` oder einer Integration mit dem Zahlungsdienstleister. Der Spesenstatus in Ramp würde auf 'Erstattet' oder 'Bezahlt' aktualisiert. Erfassen Ein `Event` wird `logged`, wenn das Zahlungssystem die erfolgreiche Zahlungsüberweisung bestätigt. Ereignistyp explicit
	Mit Buchhaltungssystem synchronisiert	Die SpesentransaktionsDaten wurden erfolgreich im integrierten Buchhaltungssystem, wie NetSuite, QuickBooks oder Xero, gebucht. Dieses Event markiert den Abschluss des finanziellen Aufzeichnungsteils des Prozesses.
Bedeutung Dies ist die finale Aktivität im End-to-End-Prozess. Verzögerungen hier können die Genauigkeit der Finanzberichterstattung und die Geschwindigkeit des Finanzabschlusses beeinträchtigen. Datenquelle In einem Integrationslog oder als Status-Update auf dem Spesenobjekt in Ramp erfasst. Suchen Sie nach einem Status wie 'Synchronisiert', 'Gebucht' oder 'Exportiert'. Erfassen Ein `Log`-Eintrag wird vom Buchhaltungs-Integrationsservice bei erfolgreicher `data`-Synchronisation erstellt. Ereignistyp explicit
	Spese angefallen	Markiert die Erstellung einer Ausgabe, in der Regel automatisch initiiert, wenn eine Firmenkreditkarte verwendet wird oder wenn ein Mitarbeiter manuell einen Auslagenbeleg erstellt. Dieses Event wird normalerweise aus TransaktionsDatenfeeds oder Benutzeroberflächenaktionen erfasst.
Bedeutung Dies ist das primäre Start-Event für den Spesen-Lebenszyklus. Die Analyse der Zeit ab diesem Event hilft, Einreichungsverzögerungen und die Gesamtprozessgeschwindigkeit zu verstehen. Datenquelle Generiert aus Ramp-Karten-Transaktions-`Logs` oder den Antrag bearbeitet.em Erstellungs-`Zeitstempel` eines manuell eingegebenen Spesenobjekts. Suchen Sie nach dem initialen Datensatz-Erstellungs-`Event` in der Spesen- oder Transaktionstabelle. Erfassen Direkt `logged`, wenn eine Kartentransaktion verarbeitet wird oder ein `user` einen neuen Speseneintrag erstellt. Ereignistyp explicit
	Spese eingereicht	Ein Mitarbeiter bestätigt, dass alle notwendigen Informationen für eine Ausgabe vollständig sind und reicht diese zur Genehmigung ein. Dies ist eine explizite `user`-`action`, die die Ausgabe von einem 'Entwurf'- oder 'Aufmerksamkeit erforderlich'-Status in einen 'Genehmigung ausstehende Zahlungen identifizieren.end'-Status überführt.
Bedeutung Diese Aktivität ist ein kritischer Meilenstein, der den Antrag bearbeitet.en Genehmigungs- und Erstattungszyklus offiziell startet. Sie ist die Basis für die Messung von Genehmigungs- und Erstattungs-SLAs. Datenquelle Erfasst aus der Status-Historie des Spesenobjekts. Dies entspricht der `user`-`action` des Einreichens der Transaktion zur Überprüfung. Erfassen `Logged`, wenn der `user` auf die Schaltfläche 'Senden' klickt, wodurch eine Statusänderung ausgelöst wird. Ereignistyp explicit
	Beleg angehängt	Stellt den Moment dar, in dem ein Beleg einer Ausgabe zugeordnet wird, entweder automatisch durch OCR-Abgleich oder manuell durch den Benutzer. Dies wird erfasst, wenn die Belegdatei erfolgreich mit dem TransaktionsDatensatz verknüpft wird.
Bedeutung Die Verfolgung dieser Aktivität hilft, durch fehlende Dokumentation verursachte Verzögerungen zu identifizieren. Sie ist ein wichtiger Schritt zur Sicherstellung der Compliance und Audit-Bereitschaft. Datenquelle `Logged` in der Spesen- oder Transaktionshistorie, wenn ein Beleg `uploaded` oder abgeglichen wird. Suchen Sie nach einem Anhangserstellungs-`Event` oder einem `flag`, das 'receipt_attached' anzeigt. Erfassen Ein `Event` wird erstellt, wenn das System ein Belegbild oder eine Datei mit dem SpesenDatensatz verknüpft. Ereignistyp explicit
	Erstattung geplant	Bei Auslagen ist der genehmigte Betrag zur Zahlungsabwicklung in die Warteschlange gestellt worden. Dieses `Event` zeigt an, dass die Spese alle Genehmigungen durchlaufen hat und zur Auszahlung bereit ist.
Bedeutung Dieser Meilenstein trennt den Genehmigungsprozess vom Zahlungsausführungsprozess. Er hilft, Verzögerungen zu isolieren, die bei der Zahlungsabwicklung im Vergleich zu denen bei Genehmigungen auftreten. Datenquelle Wahrscheinlich abgeleitet von der Statusänderung der Spese auf 'Wartet auf Erstattung' oder 'Bereit zur Zahlung' nach endgültiger Genehmigung. Kann auch ein explizites `Event` sein, wenn Zahlungen gebündelt werden. Erfassen Abgeleitet von einer Statusänderung zu 'Bereit zur Auszahlung' oder von der Erstellung eines Datensatzes in einer Zahlungsstapeltabelle. Ereignistyp inferred
	Finanzabteilung genehmigt	Das Finanzteam hat die Ausgabe geprüft und die endgültige Freigabe erteilt, womit sie für die Erstattung und den Buchungsabgleich freigegeben ist. Dies wird als explizite Benutzeraktion eines Mitglieds des Finanzteams erfasst.
Bedeutung Stellt die letzte Genehmigungsinstanz vor der Zahlung dar. Die Analyse dieser Aktivität hilft, den End-to-End-Genehmigungszyklus und die Effizienz des Finanzteams zu verstehen. Datenquelle `Logged` als `Event` in der Genehmigungshistorie der Spese. Suchen Sie nach einem Genehmigungs-`Event`, das einem `user` aus der Finanzabteilung zugeordnet ist. Erfassen Ein `Event` wird beim 'Genehmigen' durch einen `user` mit Finanzberechtigungen `logged`. Ereignistyp explicit
	Finanzprüfung ausstehende Zahlungen identifizieren.end	Eine genehmigte Ausgabe wurde eskaliert und wartet nun auf die Prüfung durch das Finanz- oder Buchhaltungsteam. Dies geschieht in der Regel bei hochpreisigen Ausgaben oder solchen mit Richtlinienkennzeichnungen. Die `Activity` wird aus einer Statusänderung abgeleitet.
Bedeutung Markiert den Beginn des Finanzprüfungszyklus. Die Messung der Dauer dieser Phase hilft, die Arbeitslast und Effizienz des Finanzteams zu bewerten und Automatisierungspotenziale zu identifizieren. Datenquelle Abgeleitet von einer Statusänderung am Spesenobjekt zu 'Wartet auf Finanzgenehmigung' nach Manager-Genehmigung. Dies erfordert Zugriff auf die Status-Historie der Spese. Erfassen Abgeleitet vom `Zeitstempel`, wenn der Spesenstatus auf 'Wartet auf Finanzprüfung' aktualisiert wird. Ereignistyp inferred
	Manager-Überprüfung ausstehende Zahlungen identifizieren.end	Die Ausgabe wurde eingereicht und wartet nun auf die Überprüfung durch den direkten Manager des Mitarbeiters. Dieser Zustand wird abgeleitet, wenn der Spesenstatus nach der Einreichung zu 'Wartet auf Genehmigung durch den Manager' oder einem ähnlichen Wert wechselt.
Bedeutung Identifiziert den Beginn der Manager-Genehmigungsphase. Die Analyse der in diesem Status verbrachten Zeit ist maßgeblich für die Messung und Verbesserung der Manager-Genehmigungs-`Durchlaufzeits`. Datenquelle Abgeleitet von einer Statusänderung am Spesenobjekt in einen Status wie 'Genehmigung ausstehende Zahlungen identifizieren.end' und Zuweisung zu einer Manager-Warteschlange. Erfordert die Verfolgung der Status-Historie. Erfassen Abgeleitet vom `Zeitstempel`, wenn der Spesenstatus 'Wartet auf Manager-Genehmigung' wird. Ereignistyp inferred
	Richtlinienprüfung durchgeführt	Das System prüft die Ausgabe automatisch anhand der konfigurierten Unternehmensrichtlinien und kennzeichnet mögliche Verstöße. Dies ist in der Regel ein systemgeneriertes Event, das kurz nach der Einreichung erfolgt.
Bedeutung Misst die Effizienz automatisierter Compliance Checks und deren Einfluss auf den Prozess. Hilft, häufige Richtlinienverstöße und Bereiche für Mitarbeiterschulungen zu identifizieren. Datenquelle Wahrscheinlich in einem `audit trail` oder `log` im Zusammenhang mit der Spesentransaktion aufgezeichnet. Suchen Sie nach System `Events`, die sich auf 'policy_check' oder 'compliance_scan' beziehen. Erfassen Ein System-`Log`-Eintrag wird erstellt, nachdem die automatisierte Richtlinien-`engine` die Transaktion verarbeitet hat. Ereignistyp explicit
	Spese zur Überarbeitung zurückgeschickt	Ein Genehmiger, entweder ein Manager oder ein Finanzprüfer, hat die Ausgabe abgelehnt und zur Korrektur an den Mitarbeiter zurückgeschickt. Dies wird durch eine Statusänderung in einen 'Überarbeitung erforderlich' oder 'Abgelehnt' Status erfasst.
Bedeutung Diese Aktivität kennzeichnet eine Überarbeitungsschleife im Prozess, die die Durchlaufzeit direkt erhöht. Die Verfolgung dieser Ereignisse hilft, häufige Einreichungsfehler zu identifizieren und die 'First-Pass Yield' zu verbessern. Datenquelle Abgeleitet von einer Statusänderung am Spesenobjekt zu 'Überarbeitung erforderlich' oder einem ähnlichen Status. Der `Event` sollte mit dem Genehmiger verknüpft sein, der den Antrag bearbeitet.ie `action` initiiert hat. Erfassen Abgeleitet vom `Zeitstempel`, wenn der Spesenstatus 'Überarbeitung erforderlich' oder 'Abgelehnt' wird. Ereignistyp inferred

Extraktionsanleitungen

So erhalten Sie Ihre `data` von Ramp

Schritte

Melden Sie sich mit Admin- oder Buchhalterberechtigungen bei Ihrem Ramp-Konto an.
Navigieren Sie im linken Menü zum Abschnitt Transaktionen. Diese Ansicht enthält alle Ausgaben mit der Firmenkreditkarte.
Wenden Sie die gewünschten Filter auf die data an. Legen Sie mindestens einen Datumsbereich für den Zeitraum fest, den Sie analysierenn möchten. Sie können auch nach anderen Eigenschaften wie Status, Kategorie oder Abteilung filtern, um den Umfang bei Bedarf einzugrenzen.
Klicken Sie oben rechts in der Transaktionsliste auf die Schaltfläche Exportieren.
Wählen Sie im Export-Modal Transaktionen als Exporttyp und CSV als Format. Laden Sie die Datei herunter und nennen Sie sie transactions_export.csv.
Navigieren Sie anschließend im linken Menü zum Abschnitt Erstattungen. Diese Ansicht enthält alle von Mitarbeitern eingereichten Auslagen.
Wenden Sie denselben Datumsbereichsfilter an, der auch für den Transaktionsexport verwendet wurde, um die data-Konsistenz zu sicherstellen.
Klicken Sie auf die Schaltfläche Exportieren und laden Sie die Erstattungs-data als CSV-Datei herunter. Nennen Sie diese Datei reimbursements_export.csv.
Legen Sie beide exportierten CSV-Dateien (transactions_export.csv und reimbursements_export.csv) im selben Verzeichnis ab wie das bereitgestellte Python-Skript.
Führen Sie das Python-Skript aus. Das Skript lädt beide Dateien, transformiert die data durch das Erstellen einer separaten Zeile für jedes Geschäftsereignis und führt sie zu einem einzigen, strukturierten Event Log zusammen.
Das Skript gibt eine Datei namens ramp_Event_log.csv aus. Diese Datei ist gemäß den ProcessMind-Anforderungen formatiert.
Laden Sie die Datei ramp_Event_log.csv zur Analyse in ProcessMind hoch.

Konfiguration

Berechtigungen: Sie müssen 'Admin'- oder 'Buchhalter'-Rollen in Ramp besitzen, um auf die vollständigen Transaktions- und ErstattungsDatensätze zugreifen und diese exportieren zu können.
Datumsbereich: Für eine erste Analyse wählen Sie einen Datumsbereich von mindestens 6 bis 12 Monaten, um genügend Prozessvarianten zu erfassen. Für die laufende Überwachung können Sie einen kürzeren, aktuelleren Zeitraum verwenden.
Datenkonsistenz: Stellen Sie sicher, dass Sie beim Export beider Dateien (Transaktionen und Erstattungen) denselben Datumsbereich und dieselben Filter verwenden, um einen konsistenten Datensatz zu sicherstellen.
Exportformat: Wählen Sie für beide Exporte immer das CSV-Format, da das Transformationsskript für die Verarbeitung von kommagetrennten Dateien ausgelegt ist.
Dateibenennung: Halten Sie sich an die Dateinamen transactions_export.csv und reimbursements_export.csv oder aktualisieren Sie die Dateipfadvariablen im Transformationsskript entsprechend.

a Beispielabfrage 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}'.")

Schritte

Voraussetzungen und Umgebungseinrichtung: Stellen Sie sicher, dass Python 3.8 oder neuer installiert ist. Installieren Sie die erforderlichen Python-Bibliotheken, indem Sie pip install requests pandas ausführen. Sie müssen außerdem Administratorzugriff auf Ihre Ramp-Instanz haben, um API-ZugangsDaten zu generieren.
Ramp API-ZugangsDaten generieren: Melden Sie sich bei Ihrem Ramp-Konto an. Navigieren Sie zu Einstellungen und wählen Sie dann im Seitenmenü Developer API. Klicken Sie auf „App erstellen“, geben Sie Ihrer Anwendung einen Namen und konfigurieren Sie die erforderlichen Scopes. Sie benötigen transactions:read, reimbursements:read und users:read. Kopieren Sie nach der Erstellung sicher die Client ID und das Client Secret.
Das Python-Skript konfigurieren: Erstellen Sie eine neue Python-Datei, zum Beispiel extract_ramp_log.py. Kopieren Sie das bereitgestellte Python-Skript in diese Datei. Legen Sie Ihre Client ID und Ihr Client Secret als Umgebungsvariablen oder den Antrag bearbeitet.irekt im Skript zu Testzwecken fest. Aus Sicherheitsgründen wird dringend empfohlen, Umgebungsvariablen zu verwenden.
Extraktionsdatumsbereich festlegen: Suchen Sie im Skript die Variablen START_DATE und END_DATE innerhalb des main-Ausführungsblocks. Passen Sie diese data an, um das Zeitfenster für die data-Extraktion zu definieren. Ein Zeitraum von 3 bis 6 Monaten wird für eine erste Analyse empfohlen.
Das Skript ausführen: Führen Sie das Skript von Ihrem Terminal aus mit dem Befehl python extract_ramp_log.py aus. Das Skript authentifiziert sich bei der Ramp-API, ruft data von den users, transactions und reimbursements-endpoints ab und handhabt die Paginierung automatisch.
API-Aufrufe verstehen: Das Skript ruft zunächst alle user-data ab, um eine Zuordnung von user IDs zu Namen und Abteilungen zu erstellen. Anschließend werden alle Erstattungen innerhalb des angegebenen Datumsbereichs abgerufen. Für jede Erstattung wird die Genehmigungs- und Zahlungshistorie extrahiert.
Daten in ein Event Log modernisieren: Die Kernlogik des Skripts durchläuft jede Erstattung und ihre zugehörige Status-Historie. Es übersetzt jede Statusänderung, wie z. B. 'MANAGER_APPROVAL' oder 'FINISHED', in eine eigenständige Activity wie 'Manager Review Pending' oder 'Reimbursement Executed'. Es ruft auch zugehörige Transaktions-data ab, um Events wie 'Expense Incurred' und 'Receipt Attached' zu erstellen.
Handling Daten Enrichment: Das Skript reichert den Event Log an, indem es user Details, AbteilungsHinweisrmationen und Spesenkategorien für jedes Event hinzufügt, wodurch ein vollständiger Datensatz für Prozessanalyse entsteht.
Die Ausgabe überprüfen: Sobald das Skript abgeschlossen ist, wird eine Datei namens ramp_Event_log.csv im selben Verzeichnis generiert. Öffnen Sie diese CSV-Datei in einem Tabellenkalkulationsprogramm, um die data zu überprüfen und sicherzustellen, dass sie wie erwartet extrahiert wurde.
Für den Upload vorbereiten: Die generierte CSV-Datei ist mit den erforderlichen Spalten strukturiert: ExpenseReportId, ActivityName, EventZeitstempel und andere empfohlene Attributes. Diese Datei ist bereit für den direkten Upload in die ProcessMind-Plattform.

Konfiguration

API-ZugangsDaten: Für die Authentifizierung sind eine gültige Client ID und ein Client Secret erforderlich. Diese werden im Ramp-Dashboard unter Einstellungen > Developer API generiert.
API-Bereiche (Scopes): Das Skript benötigt spezifische Berechtigungen für den Datenzugriff. Stellen Sie sicher, dass die folgenden Scopes für Ihren API-Key aktiviert sind: transactions:read (für Ausgaben- und Belegdetails), reimbursements:read (für Einreichung, Genehmigung und Zahlungsstatus) und users:read (für Mitarbeiternamen und Abteilung).
Datumsbereich: Die Extraktion wird durch die Parameter START_DATE und END_DATE im Skript gesteuert. Es wird empfohlen, mit einem aktuellen Zeitraum, z. B. den letzten 3-6 Monaten, zu beginnen, um den initialen Datensatz überschaubar zu halten. Der Filter wird auf das Erstellungsdatum der Erstattung angewendet.
Paginierung: Das Skript handhabt die API-Paginierung automatisch mit dem starting_after-Cursor der Ramp API. Es ruft Datensätze in Batches (bis zu 100 pro Anfrage) ab, um sicherzustellen, dass alle data innerhalb des Datumsbereichs abgerufen werden.
Ratenbegrenzung (Rate Limiting): Die Ramp API unterliegt Ratenbegrenzungen, in der Regel 600 Anfragen pro Minute. Das bereitgestellte Skript ist im Allgemeinen effizient, aber bei extrem großen Datensätzen müssen Sie möglicherweise kleine Verzögerungen zwischen API-Aufrufen einführen, falls Sie auf Rate-Limit-Fehler stoßen.

a Beispielabfrage 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()

Schritte

Melden Sie sich mit Admin- oder Buchhalterberechtigungen bei Ihrem Ramp-Konto an.
Navigieren Sie im linken Menü zum Abschnitt Transaktionen. Diese Ansicht enthält alle Ausgaben mit der Firmenkreditkarte.
Wenden Sie die gewünschten Filter auf die data an. Legen Sie mindestens einen Datumsbereich für den Zeitraum fest, den Sie analysierenn möchten. Sie können auch nach anderen Eigenschaften wie Status, Kategorie oder Abteilung filtern, um den Umfang bei Bedarf einzugrenzen.
Klicken Sie oben rechts in der Transaktionsliste auf die Schaltfläche Exportieren.
Wählen Sie im Export-Modal Transaktionen als Exporttyp und CSV als Format. Laden Sie die Datei herunter und nennen Sie sie transactions_export.csv.
Navigieren Sie anschließend im linken Menü zum Abschnitt Erstattungen. Diese Ansicht enthält alle von Mitarbeitern eingereichten Auslagen.
Wenden Sie denselben Datumsbereichsfilter an, der auch für den Transaktionsexport verwendet wurde, um die data-Konsistenz zu sicherstellen.
Klicken Sie auf die Schaltfläche Exportieren und laden Sie die Erstattungs-data als CSV-Datei herunter. Nennen Sie diese Datei reimbursements_export.csv.
Legen Sie beide exportierten CSV-Dateien (transactions_export.csv und reimbursements_export.csv) im selben Verzeichnis ab wie das bereitgestellte Python-Skript.
Führen Sie das Python-Skript aus. Das Skript lädt beide Dateien, transformiert die data durch das Erstellen einer separaten Zeile für jedes Geschäftsereignis und führt sie zu einem einzigen, strukturierten Event Log zusammen.
Das Skript gibt eine Datei namens ramp_Event_log.csv aus. Diese Datei ist gemäß den ProcessMind-Anforderungen formatiert.
Laden Sie die Datei ramp_Event_log.csv zur Analyse in ProcessMind hoch.

Konfiguration

Berechtigungen: Sie müssen 'Admin'- oder 'Buchhalter'-Rollen in Ramp besitzen, um auf die vollständigen Transaktions- und ErstattungsDatensätze zugreifen und diese exportieren zu können.
Datumsbereich: Für eine erste Analyse wählen Sie einen Datumsbereich von mindestens 6 bis 12 Monaten, um genügend Prozessvarianten zu erfassen. Für die laufende Überwachung können Sie einen kürzeren, aktuelleren Zeitraum verwenden.
Datenkonsistenz: Stellen Sie sicher, dass Sie beim Export beider Dateien (Transaktionen und Erstattungen) denselben Datumsbereich und dieselben Filter verwenden, um einen konsistenten Datensatz zu sicherstellen.
Exportformat: Wählen Sie für beide Exporte immer das CSV-Format, da das Transformationsskript für die Verarbeitung von kommagetrennten Dateien ausgelegt ist.
Dateibenennung: Halten Sie sich an die Dateinamen transactions_export.csv und reimbursements_export.csv oder aktualisieren Sie die Dateipfadvariablen im Transformationsskript entsprechend.

a Beispielabfrage 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}'.")

Ihr Template für Spesenmanagement-Daten

Ihr Template für Spesenmanagement-Daten

Spesenmanagement-Attribute

Spesenmanagement-Aktivitäten

Extraktionsanleitungen

Ramp Integrierter CSV Transaktions- und Erstattungsexport

Schritte

Konfiguration

a Beispielabfrage config

Python Skript-Extraktion über die Ramp Developer API

Schritte

Konfiguration

a Beispielabfrage python

Ramp Daten Warehouse Integration Sync (Snowflake/BigQuery)

Schritte

Konfiguration

a Beispielabfrage config

Bereit, um loszulegen?

Effizienz steigern: Ramp Spesenmanagement heute optimieren

Ihr Template für Spesenmanagement-Daten

Ihr Template für Spesenmanagement-Daten

Spesenmanagement-Attribute

Spesenmanagement-Aktivitäten

Extraktionsanleitungen

Ramp Integrierter CSV Transaktions- und Erstattungsexport

Schritte

Konfiguration

a Beispielabfrage config

Python Skript-Extraktion über die Ramp Developer API

Schritte

Konfiguration

a Beispielabfrage python

Ramp Daten Warehouse Integration Sync (Snowflake/BigQuery)

Schritte

Konfiguration

a Beispielabfrage config

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Effizienz steigern: Ramp Spesenmanagement heute optimieren