> Kontinuierliche Prozessoptimierung > Spesenmanagement > Ramp > Datenvorlage

Ihr Daten-Template für das Spesenmanagement

Ramp

Spesenmanagement `Attributes` (23) Spesenmanagement `Activities` (12) Extraktionsleitfäden (3)

Ihr Daten-Template für das Spesenmanagement

Dieses Template bietet eine klare Roadmap zur Sammlung der notwendigen Daten, um Ihren Spesenmanagementprozess zu analysieren und zu optimieren. Es umreißt wesentliche Attribute, wichtige zu verfolgende Aktivitäten und praktische Anleitungen zur Datenextraktion aus Ramp. Nutzen Sie diese Ressource, um sicherzustellen, dass Sie alle Informationen für eine aufschlussreiche Prozessentdeckung und -verbesserung sammeln.

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

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

Vorlage herunterladen

Spesenmanagement `Attributes`

Dies sind die wesentlichen Datenfelder, die in Ihrem Event Log für eine umfassende Analyse Ihres Spesenmanagementprozesses enthalten sein sollten.

3 Erforderlich 6 Empfohlen 14 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des spezifischen Events oder der Task, 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 Vorgänge und zur Messung der Performance 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 typischerweise aus Event Logs oder Statusänderungsdatensätzen abgeleitet, die mit jeder Spesenabrechnung in Ramp verbunden sind. Beispiele Spese eingereichtDurch Manager freigegebenFinanzprüfung ausstehendErstattung ausgeführt
	Ereignis-Timestamp EventTimestamp	Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat.
Beschreibung Jede `Activity` im Prozess hat einen entsprechenden `timestamp`, 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 `timestamps` verwendet, um `Cycle Times` zwischen `activities` zu berechnen, die Gesamtdauer eines `case` zu messen und Verzögerungen zu identifizieren. Diese Informationen sind entscheidend für das `Performance Monitoring` und die Identifizierung von Möglichkeiten zur Prozessverbesserung. Bedeutung Dieses Attribut liefert die chronologische Reihenfolge der Events und ist essenziell für alle Dauerberechnungen und Performance-Analysen. Datenquelle Diese Information findet sich typischerweise 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
	Spesenbericht-ID ExpenseReportId	Der eindeutige Identifikator für jede Spesenabrechnung, der als primärer Case-Identifikator für den Prozess dient.
Beschreibung Die Spesenabrechnungs-ID gruppiert alle Events 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-Weg 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 die ID des Benutzers, der die Aktivität durchgeführt hat, einschließlich des Mitarbeiters, der die Ausgabe einreicht, oder des 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 lokalisieren, die möglicherweise zusätzliche Schulungen benötigen. Es ist entscheidend für Dashboards zur Genehmigungs-Performance und zum Ressourcenmanagement. Bedeutung Es ordnet Prozess `activities` bestimmten Personen zu, ermöglicht eine `Performance Analysis` auf Ressourcenebene und identifiziert Schulungsbedarfe. Datenquelle Benutzerinformationen werden typischerweise im Prüfpfad oder in der Transaktionshistorie für jede Spesenabrechnung in Ramp protokolliert. Beispiele Alice JohnsonBob SmithCharlie BrownSystem Automation
	Gesamtbetrag des Berichts ReportTotalAmount	Der monetäre Gesamtwert der Spesenabrechnung.
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 Cases zu segmentieren und zu untersuchen, ob hochpreisige Berichte unterschiedliche Genehmigungspfade verfolgen oder länger dauern. Es ist grundlegend für Spend Analysis Dashboards und zur Identifizierung von Kosteneinsparungspotenzialen. Bedeutung Es bietet eine entscheidende 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 typischerweise einen Grund an. Dieses Attribut erfasst diesen Grund, wie z.B. 'Beleg fehlt', 'Falsche Kategorie' oder 'Außerhalb der Richtlinie'. Diese Information ist von unschätzbarem Wert 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 detaillierter BelegSpese überschreitet RichtliniengrenzeFalsche Spesenkategorie ausgewähltDoppelte Transaktion
	Kennzeichnung eines Richtlinienverstoßes PolicyViolationFlag	Ein `Flag`, das anzeigt, ob der Spesenbericht wegen eines Richtlinienverstoßes markiert wurde.
Beschreibung Dieses boolesche Attribut wird auf 'true' gesetzt, wenn die automatisierten Systemprüfungen einen potenziellen Verstoß gegen die Unternehmensspesenrichtlinien erkennen, wie z.B. die Überschreitung eines Ausgabenlimits oder die Einreichung einer doppelten Ausgabe. Dieses Flag ist entscheidend 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 truefalsch
	Mitarbeiterabteilung EmployeeDepartment	Die Abteilung des Mitarbeiters, der die Spesenabrechnung eingereicht hat.
Beschreibung Dieses Attribut gibt die Geschäftseinheit oder Abteilung an, zu der der 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-Performance ü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
	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 typischerweise ein Posten-Ebene-Detail auf der Spesenabrechnung in Ramp. Daten müssen möglicherweise auf Berichtsebene für einige Analysen aggregiert werden. Beispiele FlugkostenBewirtung und UnterhaltungSoftware-AbonnementBü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 die 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
	Audit-Ergebnis 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 Performance“. Sie helfen bei der Bewertung der Effektivität des `Audit`-Prozesses, der Verfolgung der Häufigkeit verschiedener Ergebnisse und dem Verständnis der finanziellen Auswirkungen von `Audit`-Erkenntnissen. Bedeutung Es misst die Effektivität und Ergebnisse 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 genehmigtAbgelehntEskaliert
	Buchungszeit im Rechnungswesen AccountingPostingTime	Die Zeit von der Ausführung einer Erstattung bis zur Buchung der Transaktion im Buchhaltungssystem.
Beschreibung Diese berechnete Metrik misst die Verzögerung in der Finanzbuchführung. Es ist die Zeitdifferenz zwischen dem Event 'Erstattung ausgeführt' und dem Event 'Mit Buchhaltungssystem synchronisiert'. Dieses Attribut wird für den KPI 'Durchschnittliche Buchungszeit im Rechnungswesen' und das Dashboard 'Verzögerungen bei Buchungen im Rechnungswesen' verwendet. Es hilft sicherzustellen, dass Finanzunterlagen umgehend aktualisiert werden, was für eine genaue und zeitnahe Finanzberichterstattung wichtig ist. Bedeutung Es zeigt Verzögerungen in der Finanzbuchhaltung auf und ermöglicht Maßnahmen zur Beschleunigung des Buchhaltungsabschlussprozesses. Datenquelle Dies wird aus den Event Timestamps im Data Log für Erstattungs- und Buchungsabgleichs-Events berechnet. Beispiele 2 Stunden1 Tag5 Minuten
	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 die 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-Events in den System Logs von Ramp erfasst werden. Beispiele Mobile AppWeb-PortalE-Mail
	Endzeit des Events EventEndTime	Der Timestamp, 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 essenziell für KPIs wie 'Durchschnittliche Dauer der Richtlinienprüfung' und zur genauen Identifizierung, wie lange spezifische automatisierte oder manuelle Tasks innerhalb des Gesamtprozesses zur Fertigstellung benötigen. Bedeutung Es ermöglicht die präzise Berechnung individueller `activity` Dauern, was entscheidend ist, um ineffiziente Prozessschritte zu identifizieren. Datenquelle Für `activities` mit einer Dauer würde dies in den `event data` 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-Performance nach Methode hilft, die effizientesten Zahlungskanäle zu identifizieren. Das Dashboard 'Erstattungsmethoden-Performance' 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 die Spesenabrechnung genehmigt hat.
Beschreibung Für `Workflows`, die einen Finanzprüfungsschritt umfassen, identifiziert dieses `Attribute` die spezifische Person oder das 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, `Bottlenecks` zu identifizieren, die Arbeitslastverteilung zu bewerten und die Effektivität der Finanzprüfungsphase zu messen. Bedeutung Es ermöglicht eine detaillierte `Performance 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`
	Finanzprüfungszeit FinanceReviewTime	Die Zeit, die eine Spesenabrechnung in der Finanzprüfungsphase verbringt.
Beschreibung Diese Metrik misst die Dauer von dem Zeitpunkt, an dem ein Bericht in die Finanzwarteschlange gelangt ('Finanzprüfung ausstehend'), bis ein Finanzgenehmiger Maßnahmen ergreift ('Finanzabteilung genehmigt' oder 'Finanzabteilung abgelehnt'). Es ist das primäre Maß für den KPI 'Durchschnittliche Finanzprüfungszeit' und das Dashboard 'Effizienz der Finanzprüfung'. Die Analyse dieser Dauer hilft, Möglichkeiten zur Optimierung oder Automatisierung des Finanzprüfungsprozesses zu identifizieren, wodurch der manuelle Aufwand reduziert und der gesamte Zyklus beschleunigt wird. Bedeutung Es misst die Effizienz des Finanzprüfungs-Prozesses und hebt Möglichkeiten für Automatisierung und Straffung hervor. Datenquelle Dieser Wert wird aus den Event Timestamps für den Start und das Ende der Finanzprüfungsaktivitäten berechnet. Beispiele 4 Stunden1 Tag 2 Stunden18 Stunden
	Genehmigender Manager ApprovingManager	Der Name des Managers, der den 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 Bericht eingereicht hat. Die Verfolgung des genehmigenden Managers ist essenziell für das Dashboard 'Manager Genehmigungs-Durchlaufzeit'. Es ermöglicht die Analyse der Genehmigungslasten und der Performance 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 `Performance Analysis` einzelner Genehmiger und hilft, `Bottlenecks` 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
	Gesamte Erstattungs-Durchlaufzeit TotalReimbursementCycleTime	Die gesamte verstrichene Zeit von der Einreichung einer Spesenabrechnung bis zur Ausführung der Erstattung.
Beschreibung Diese berechnete Metrik misst die End-to-End-Dauer des Erstattungsprozesses aus der Sicht des Mitarbeiters. Sie wird als Zeitdifferenz zwischen den Events 'Ausgabe eingereicht' und 'Erstattung ausgeführt' für jeden Case berechnet. Dieses Attribut ist die Grundlage für den KPI 'Durchschnittliche Erstattungs-Durchlaufzeit' und das Dashboard 'End-to-End Erstattungszyklus'. Es bietet ein übergeordnetes Maß für die Prozesseffizienz und ist ein wichtiger Indikator für die Mitarbeiterzufriedenheit. Bedeutung Es quantifiziert die gesamte Prozessdauer und liefert einen wichtigen `Key Performance Indicator` zur Messung der End-to-End-Effizienz. Datenquelle Dies wird während der Datentransformation berechnet, indem der Timestamp des ersten Einreichungs-Events vom finalen Erstattungs-Event subtrahiert wird. Beispiele 3 Tage 4 Stunden10 Tage 1 Stunde1 Tag 8 Stunden
	Ist Nacharbeit IsRework	Ein berechnetes `Flag`, 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 'true' 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 Kohorten 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 truefalsch
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, der den 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 entscheidend für die korrekte Interpretation der Ergebnisse. Dieses Attribut hilft Benutzern zu verstehen, ob sie aktuelle Informationen betrachten. Bedeutung Es informiert `users` über die Aktualität der `data` und stellt sicher, dass Analysen auf aktuellen und relevanten Informationen basieren. Datenquelle Dieser Timestamp wird während des Datenextraktionsprozesses generiert und hinzugefügt. Beispiele 2023-11-01T06:00:00Z
	Manager-Genehmigungszeit ManagerApprovalTime	Die Zeit, die von der ausstehenden Managerprüfung eines Berichts bis zur Genehmigung oder Ablehnung durch den Manager vergeht.
Beschreibung Diese Metrik berechnet die Dauer der Manager-Genehmigungsphase. Es ist die Zeitdifferenz zwischen der Aktivität 'Manager-Überprüfung ausstehend' und der nachfolgenden Aktivität 'Manager genehmigt' oder 'Manager abgelehnt'. Diese Dauer wird verwendet, um den KPI 'Durchschnittliche Manager-Genehmigungszeit' zu berechnen und das Dashboard 'Manager Genehmigungs-Durchlaufzeit' zu versorgen. Es hilft, Verzögerungen in der ersten Genehmigungsebene zu lokalisieren, die oft einen erheblichen Engpass darstellt. Bedeutung Es isoliert die Dauer eines kritischen Genehmigungsschritts und hilft, `Bottlenecks` zu identifizieren und zu beheben, die durch Manager-Prüfungen verursacht werden. Datenquelle Dies wird aus dem Event Log berechnet, indem die Zeitdifferenz zwischen den ausstehenden Manager-Review- und den Abschluss-Events ermittelt wird. Beispiele 1 Stunde 15 Minuten2 Tage 3 Stunden5 Stunden 30 Minuten
	Quellsystem SourceSystem	Identifiziert die Quellanwendung, aus der die `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 gewährleisten. 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 entscheidend ist. Datenquelle Dies ist typischerweise ein statischer Wert ('Ramp'), der während des Datenextraktions- und Transformationsprozesses hinzugefügt wird. Beispiele Ramp

Erforderlich Empfohlen Optional

Spesenmanagement `Activities`

Dies sind die zentralen Prozessschritte und Meilensteine, die Sie in Ihrem Event Log erfassen sollten – für eine präzise Process Discovery und eine zuverlässige Performance-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 entscheidender Meilenstein, der den erfolgreichen Abschluss der ersten Genehmigungsebene anzeigt. Es ist entscheidend 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 Timestamp 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 typischerweise 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, typischerweise 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 dem Erstellungs-`timestamp` 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 ausstehend'-Status überführt.
Bedeutung Diese Aktivität ist ein kritischer Meilenstein, der den 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 ausstehend	Eine genehmigte Ausgabe wurde eskaliert und wartet nun auf die Prüfung durch das Finanz- oder Buchhaltungsteam. Dies geschieht typischerweise 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 `Timestamp`, wenn der Spesenstatus auf 'Wartet auf Finanzprüfung' aktualisiert wird. Ereignistyp inferred
	Manager-Überprüfung ausstehend	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 entscheidend für die Messung und Verbesserung der Manager-Genehmigungs-`Cycle Times`. Datenquelle Abgeleitet von einer Statusänderung am Spesenobjekt in einen Status wie 'Genehmigung ausstehend' und Zuweisung zu einer Manager-Warteschlange. Erfordert die Verfolgung der Status-Historie. Erfassen Abgeleitet vom `Timestamp`, 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 typischerweise 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 Events 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 die `action` initiiert hat. Erfassen Abgeleitet vom `Timestamp`, wenn der Spesenstatus 'Überarbeitung erforderlich' oder 'Abgelehnt' wird. Ereignistyp inferred

Extraktionsleitfäden

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 analysieren 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 gewährleisten.
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 gewährleisten.
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 direkt 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.
Data in ein Event Log transformieren: 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 Data Enrichment: Das Skript reichert den Event Log an, indem es user Details, Abteilungsinformationen und Spesenkategorien für jedes event hinzufügt, wodurch ein umfassender 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, EventTimestamp 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, typischerweise 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 analysieren 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 gewährleisten.
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 gewährleisten.
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 Daten-Template für das Spesenmanagement

Ihr Daten-Template für das Spesenmanagement

Spesenmanagement `Attributes`

Spesenmanagement `Activities`

Extraktionsleitfäden

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 Data Warehouse Integration Sync (Snowflake/BigQuery)

Schritte

Konfiguration

a Beispielabfrage config

Bereit, um loszulegen?

Effizienz freisetzen: Ramp Spesenmanagement heute optimieren

Ihr Daten-Template für das Spesenmanagement

Ihr Daten-Template für das Spesenmanagement

Spesenmanagement Attributes

Spesenmanagement Activities

Extraktionsleitfäden

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 Data Warehouse Integration Sync (Snowflake/BigQuery)

Schritte

Konfiguration

a Beispielabfrage config

Ihre Privatsphäre ist uns wichtig

Bereit, um loszulegen?

Effizienz freisetzen: Ramp Spesenmanagement heute optimieren

Spesenmanagement `Attributes`

Spesenmanagement `Activities`