> Continue verbetering > `Expense Management` > Ramp > datatemplate

Uw template voor onkostenbeheer data

Ramp

`Expense Management Attributes` (23) `Expense Management Activities` (12) Extractie Guides (3)

Uw template voor onkostenbeheer data

Deze template biedt een heldere routekaart voor het verzamelen van de benodigde data om uw onkostenbeheerproces te analyseren en optimaliseren. Het beschrijft essentiële attributen, belangrijke te volgen activiteiten en praktische begeleiding voor het extraheren van uw data uit Ramp. Gebruik deze bron om ervoor te zorgen dat u alle informatie verzamelt die nodig is voor inzichtelijke procesontdekking en -verbetering.

Aanbevolen attributen om vast te leggen
Belangrijkste activiteiten om te volgen
Extractiehandleiding voor Ramp

Nieuw met event logs? Leer hoe je een process mining event log creëert.

Template downloaden

`Expense Management Attributes`

Dit zijn de essentiële data velden om op te nemen in uw event log voor een uitgebreide analyse van uw onkostenbeheerproces.

3 Verplicht 6 Aanbevolen 14 Optioneel

	Naam	Omschrijving
	`Declaratie-ID` ExpenseReportId	De unieke identifier voor elk onkostenrapport, dienend als de primaire case identifier voor het proces.
Omschrijving De Onkostenrapport ID groepeert alle gebeurtenissen en activiteiten die verband houden met één indiening van uitgaven. Het maakt een complete, chronologische tracking mogelijk van een onkostenclaim vanaf de initiële invoer tot de uiteindelijke betaling. In process mining is dit attribuut essentieel voor het reconstrueren van het end-to-end traject van elk onkostenrapport. Door het als de case ID te gebruiken, kunnen analyses nauwkeurig doorlooptijden berekenen, knelpunten identificeren en de verschillende paden visualiseren die rapporten door het goedkeuringsproces nemen. Het belang Dit is het fundamentele attribuut dat alle gerelateerde activiteiten koppelt tot één enkele procesinstantie, waardoor end-to-end analyse mogelijk wordt. Vindplaats Deze identificatie moet beschikbaar zijn in de hoofdtafel van onkostendeclaraties of transacties binnen Ramp. Voorbeelden ER-2023-08-1123ER-2023-09-4591ER-2023-10-0024
	Activiteitsnaam ActivityName	De naam van de specifieke gebeurtenis of taak die op een bepaald moment binnen het onkostenbeheerproces heeft plaatsgevonden.
Omschrijving Dit attribuut beschrijft een enkele stap in de levenscyclus van het onkostenrapport, zoals 'Uitgave Ingediend', 'Manager Goedgekeurd' of 'Vergoeding Uitgevoerd'. Deze activiteiten vormen de knooppunten in de proceskaart, wat visualisatie en analyse van de processtroom mogelijk maakt. Het analyseren van activiteiten helpt bij het identificeren van de meest frequente stappen, waar knelpunten optreden en hoe verschillende workflows variëren. Het is een kerncomponent voor het begrijpen van de volgorde van bewerkingen en het meten van prestaties in elke fase. Het belang Het definieert de `steps` in de `process map`, wat de `visualisatie` en `analyse` van de `process flow` van begin tot eind mogelijk maakt. Vindplaats Dit wordt doorgaans afgeleid uit event logs of statuswijzigingsrecords die gekoppeld zijn aan elk onkostenrapport in Ramp. Voorbeelden `Uitgave` IngediendDoor manager goedgekeurd`Finance Review` WachtendVergoeding Uitgevoerd
	Gebeurtenistijdstempel EventTimestamp	De exacte datum en tijd waarop de activiteit plaatsvond.
Omschrijving Elke `activity` in het `proces` heeft een corresponderende `timestamp` die vastlegt wanneer deze plaatsvond. Deze `temporele data` wordt gebruikt om `events` chronologisch te ordenen en is de basis voor alle tijdsgerelateerde `analyse`. In `process mining` worden `timestamps` gebruikt om `cycle times` tussen `activities` te berekenen, de totale `duration` van een `case` te meten en `vertragingen` te identificeren. Deze `informatie` is cruciaal voor `performance monitoring` en het identificeren van `kansen` voor `procesverbetering`. Het belang Dit attribuut geeft de chronologische volgorde van gebeurtenissen weer en is essentieel voor alle duur berekeningen en prestatieanalyse. Vindplaats Deze informatie is doorgaans te vinden naast de activiteits- of statusrecords in de event logs of transactie data van Ramp. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T14:30:00Z2023-10-27T09:00:00Z
	`Uitgavencategorie` ExpenseCategory	De categorie die aan een uitgave is toegewezen, zoals 'Reizen', 'Software' of 'Maaltijden'.
Omschrijving Dit attribuut classificeert uitgaven in vooraf gedefinieerde categorieën, wat helpt bij het volgen en controleren van bedrijfsuitgaven. Eén onkostenrapport kan items uit meerdere categorieën bevatten. Analyseren per uitgavencategorie is essentieel voor het 'Uitgavencategorie Analyse' dashboard. Het helpt finance teams te begrijpen waar geld wordt uitgegeven, budget naleving te bewaken en trends of afwijkingen in uitgaven in de loop van de tijd te identificeren. Het belang Het maakt gedetailleerde `spend analysis` mogelijk, wat helpt bij het identificeren van belangrijke `cost drivers` en `kansen` voor `budgetoptimalisatie`. Vindplaats Dit is doorgaans een detail op regelniveau in het onkostenrapport in Ramp. Data moet mogelijk worden geaggregeerd naar rapportniveau voor sommige analyses. Voorbeelden VliegticketsMaaltijden en EntertainmentSoftware AbonnementKantoorbenodigdheden
	Afdeling Werknemer EmployeeDepartment	De afdeling van de medewerker die het onkostenrapport heeft ingediend.
Omschrijving Dit attribuut geeft de business unit of afdeling aan waartoe de medewerker die de uitgave indient behoort, zoals 'Verkoop', 'Engineering' of 'Marketing'. Dit is een kritische dimensie voor analyse, aangezien het filtering en vergelijking van procesprestaties in verschillende delen van de organisatie mogelijk maakt. Het kan variaties in goedkeuringstijden, revisiepercentages en beleidscompliance tussen afdelingen onthullen, ter ondersteuning van gerichte verbeterinitiatieven. Het belang Het maakt vergelijking van `process metrics` mogelijk tussen verschillende `business units`, waarbij `variaties` in `efficiëntie`, `compliance` en `uitgaven` worden benadrukt. Vindplaats Deze informatie is waarschijnlijk gekoppeld aan het gebruikersprofiel van de medewerker in Ramp of een geïntegreerd HR-systeem. Voorbeelden VerkoopMarketingEngineeringFinanciën
	Gebruikersnaam UserName	De naam of ID van de gebruiker die de activiteit heeft uitgevoerd, inclusief de medewerker die de uitgave indient of de goedkeurder.
Omschrijving Dit attribuut identificeert de persoon die verantwoordelijk is voor een specifieke gebeurtenis in het proces, zoals het indienen, goedkeuren of beoordelen van een onkostenrapport. Dit kan de naam van een medewerker zijn of een unieke gebruikers-ID. Analyseren per gebruiker helpt om de werkverdeling te begrijpen, toppresteerders te identificeren en personen aan te wijzen die mogelijk extra training nodig hebben. Het is essentieel voor dashboards met betrekking tot goedkeuringsprestaties en resource management. Het belang Het `attribueert` `process activities` aan specifieke individuen, wat `performance analysis` op `resource level` mogelijk maakt en `training needs` identificeert. Vindplaats Gebruikersinformatie wordt doorgaans vastgelegd in de audit trail of transactiehistorie voor elk onkostenrapport in Ramp. Voorbeelden Alice JohnsonBob SmithCharlie BrownSysteemautomatisering
	Reden Revisie RevisionReason	De reden die wordt opgegeven wanneer een onkostenrapport ter revisie naar de medewerker wordt teruggestuurd.
Omschrijving Wanneer een goedkeurder een onkostenrapport afwijst of terugstuurt, geeft deze doorgaans een reden op. Dit attribuut legt die reden vast, zoals 'Bon Ontbreekt', 'Incorrecte Categorie' of 'Buiten Beleid'. Deze informatie is van onschatbare waarde voor het 'Revisiepercentage Onkosten en Oorzaken' dashboard. Door de meest voorkomende redenen voor herstelwerk te analyseren, kunnen organisaties systemische problemen in het indieningsproces identificeren en gerichte training of systeemverbeteringen implementeren om fouten te verminderen. Het belang Het biedt direct `inzicht` in de `grondoorzaken` van `rework`, waardoor gerichte `actions` mogelijk zijn om de `first-time submission quality` te verbeteren. Vindplaats Deze data zou worden vastgelegd in de opmerkingen of afkeuringsdetails wanneer de activiteit 'Uitgave Teruggestuurd voor Revisie' plaatsvindt in Ramp. Voorbeelden Ontbrekende gespecificeerde bon`Uitgave` overschrijdt `beleidslimiet`Onjuiste `uitgavencategorie` geselecteerdDubbele `transactie`
	Totaalbedrag Rapport ReportTotalAmount	De totale geldwaarde van het onkostenrapport.
Omschrijving Dit attribuut vertegenwoordigt de som van alle uitgaven die in één rapport zijn opgenomen. Het is een belangrijke financiële metric voor het begrijpen van uitgavenpatronen. In procesanalyse kan het rapportbedrag worden gebruikt om cases te segmenteren en te onderzoeken of rapporten met een hoge waarde verschillende goedkeuringspaden volgen of langer duren om te verwerken. Het is fundamenteel voor dashboards voor uitgavenanalyse en voor het identificeren van kostenbesparende mogelijkheden. Het belang Het biedt een cruciale `financiële dimensie` voor `analyse`, waardoor `segmentatie` van `rapporten` op `waarde` en het volgen van de algehele `spend` mogelijk is. Vindplaats Dit is een primair veld op het object van de onkostendeclaratie in Ramp. Voorbeelden 150.752500.0089.99
	Vlag Beleidsschending PolicyViolationFlag	Een `flag` die aangeeft of de `declaratie` werd `gemarkeerd` voor een `beleidsovertreding`.
Omschrijving Dit booleaanse attribuut wordt op 'true' gezet als de geautomatiseerde controles van het systeem een potentiële schending van het bedrijfsbeleid voor uitgaven detecteren, zoals het overschrijden van een bestedingslimiet of het indienen van een dubbele uitgave. Deze vlag is cruciaal voor het 'Detectie Beleidsschending' dashboard en de bijbehorende KPI. Het helpt de effectiviteit van beleidscontroles te meten en veelvoorkomende gebieden van non-compliance te identificeren, wat kan leiden tot beleidsupdates of medewerkerstraining. Het belang Het meet direct de `beleidscompliance`, wat helpt bij het identificeren en verminderen van `non-compliant spending` en bijbehorende `risico's`. Vindplaats Dit is waarschijnlijk een door het systeem gegenereerde vlag binnen Ramp, geactiveerd door geautomatiseerde beleidscontroles tijdens het indienings- of goedkeuringsproces. Voorbeelden truefalse
	`Audit Resultaat` AuditOutcome	Het resultaat van een interne of externe audit van het onkostenrapport.
Omschrijving Voor `declaraties` die een formele `audit` ondergaan, registreert dit `attribute` het definitieve `resultaat`, zoals 'Approved', 'Partially Denied' of 'Further Information Required'. Deze `data` is centraal voor het 'Expense Audit Performance' `dashboard`. Het helpt bij het evalueren van de effectiviteit van het `audit process`, het volgen van de frequentie van verschillende `outcomes`, en het begrijpen van de `financiële impact` van `audit findings`. Het belang Het meet de effectiviteit en `resultaten` van het `audit process`, en biedt `inzichten` in `compliance` en `control weaknesses`. Vindplaats Dit zou worden vastgelegd in de audit module van Ramp of een geïntegreerd systeem indien dit wordt gebruikt voor gedetailleerde onkostencontrole. Voorbeelden GeslaagdGoedgekeurd met OpmerkingenAfgewezenGeëscaleerd
	`Finance Review` Tijd FinanceReviewTime	De tijd die een onkostenrapport doorbrengt in de financiële beoordelingsfase.
Omschrijving Deze metric meet de duur vanaf het moment dat een rapport de financiële wachtrij ingaat ('Financiële Beoordeling Wachtend') totdat een financiële goedkeurder actie onderneemt ('Financieel Goedgekeurd' of 'Financieel Afgewezen'). Het is de primaire maatstaf voor de KPI 'Gemiddelde Financiële Beoordelingstijd' en het 'Financiële Beoordeling Efficiëntie' dashboard. Het analyseren van deze duur helpt bij het identificeren van mogelijkheden om het financiële beoordelingsproces te stroomlijnen of te automatiseren, waardoor handmatige inspanning wordt verminderd en de totale cyclus wordt versneld. Het belang Het meet de `efficiëntie` van het `review process` van de `finance afdeling`, waarbij `kansen` voor `automation` en `streamlining` worden benadrukt. Vindplaats Deze waarde wordt berekend uit de event timestamps voor de start en het einde van de financiële beoordelingsactiviteiten. Voorbeelden 4 uur1 dag 2 uur18 uur
	`Finance` Goedkeurder FinanceApprover	De gebruiker van het finance team die het onkostenrapport heeft goedgekeurd.
Omschrijving Voor `workflows` die een `finance review step` omvatten, identificeert dit `attribute` de specifieke persoon of het `team` binnen de `finance afdeling` die de definitieve `approval` heeft uitgevoerd. Dit `attribute` ondersteunt het 'Finance Review Efficiency' `dashboard` door `performance` te analyseren op individueel of `teamniveau`. Het helpt `bottlenecks` te identificeren, `werklastverdeling` te beoordelen en de effectiviteit van de `finance review stage` te meten. Het belang Het maakt gedetailleerde `performance analysis` van de `finance review step` mogelijk, wat helpt bij het optimaliseren van een kritiek `controlepunt` in het `proces`. Vindplaats Dit zou worden vastgelegd in de goedkeuringshistorie van het onkostenrapport in Ramp tijdens de financiële beoordelingsfase. Voorbeelden Finance Team ADavid Lee`Finance Automation Bot`
	`Manager Approval` Tijd ManagerApprovalTime	De tijd die verstrijkt vanaf het moment dat een rapport in afwachting is van beoordeling door de manager tot het moment dat de manager het goedkeurt of afwijst.
Omschrijving Deze metric berekent de duur van de manager goedkeuringsfase. Het is het tijdsverschil tussen de activiteit 'Manager Beoordeling Wachtend' en de daaropvolgende activiteit 'Manager Goedgekeurd' of 'Manager Afgewezen'. Deze duur wordt gebruikt om de KPI 'Gemiddelde Manager Goedkeuringstijd' te berekenen en het 'Manager Goedkeuringsdoorlooptijd' dashboard van data te voorzien. Het helpt vertragingen in het eerste goedkeuringsniveau, dat vaak een significant knelpunt is, vast te stellen. Het belang Het isoleert de `duration` van een kritieke `approval step`, wat helpt bij het identificeren en aanpakken van `bottlenecks` veroorzaakt door `manager reviews`. Vindplaats Dit wordt berekend uit het event log door het tijdsverschil te vinden tussen de manager review pending en voltooiings gebeurtenissen. Voorbeelden 1 uur 15 minuten2 dagen 3 uur5 uur 30 minuten
	Aantal Goedkeuringsstappen ApprovalStepCount	Het totale aantal formele goedkeuringsstappen die een onkostenrapport heeft doorlopen.
Omschrijving Deze berekende metric telt het aantal verschillende goedkeuringsactiviteiten, zoals 'Manager Goedgekeurd' en 'Financieel Goedgekeurd', die hebben plaatsgevonden voor één onkostenrapport. Het helpt de complexiteit van de goedkeurings workflow te kwantificeren. Dit attribuut wordt gebruikt voor de KPI 'Gemiddeld Aantal Goedkeuringsstappen per Rapport' en het 'Eenvoudige Goedkeuringspaden voor Onkosten' dashboard. Door deze telling te analyseren, vooral in relatie tot de waarde of categorie van het rapport, kunnen organisaties identificeren of eenvoudige, laagwaardige uitgaven onderworpen zijn aan overdreven complexe goedkeuringsprocessen. Het belang Het kwantificeert `workflow complexity`, wat helpt bij het identificeren van `kansen` voor `simplificatie`, vooral voor `low-risk reports`. Vindplaats Dit wordt berekend door het aantal voorkomende, goedkeuringsgerelateerde activiteiten binnen elke case in het event log te tellen. Voorbeelden 123
	Boekhoudkundige Boekingstijd AccountingPostingTime	De tijd vanaf het moment dat een vergoeding wordt uitgevoerd totdat de transactie in het boekhoudsysteem wordt geboekt.
Omschrijving Deze berekende metric meet de vertraging in de financiële boekhouding. Het is het tijdsverschil tussen de gebeurtenis 'Vergoeding Uitgevoerd' en de gebeurtenis 'Gesynchroniseerd met Boekhoudsysteem'. Dit attribuut wordt gebruikt voor de KPI 'Gemiddelde Boekingstijd Boekhouding' en het 'Boekingsvertragingen Boekhouding' dashboard. Het helpt ervoor te zorgen dat financiële records snel worden bijgewerkt, wat belangrijk is voor nauwkeurige en tijdige financiële rapportage. Het belang Het benadrukt vertragingen in de `financiële verslaglegging`, waardoor `actions` mogelijk zijn om het `accounting close process` te versnellen. Vindplaats Dit wordt berekend op basis van de event timestamps in de datalog voor vergoedings- en boekhoudkundige synchronisatiegebeurtenissen. Voorbeelden 2 uur1 dag5 minuten
	Bronsysteem SourceSystem	Identificeert de `source application` waaruit de `data` is geëxtraheerd.
Omschrijving Dit attribuut specificeert het systeem van registratie voor de proces data, wat in dit geval Ramp is. Het is nuttig in omgevingen waar data mogelijk wordt gemengd uit meerdere systemen, wat zorgt voor een duidelijke data lineage. Voor analyse helpt het bij het filteren van data uit een specifieke bron en kan het worden gebruikt voor data validatie en governance doeleinden. Het belang Het biedt `context` over de `data`'s `origin`, wat cruciaal is voor `data governance` en bij het `integreren` van `data` uit meerdere `systemen`. Vindplaats Dit is doorgaans een statische waarde ('Ramp') die wordt toegevoegd tijdens het data-extractie- en transformatieproces. Voorbeelden Ramp
	Eindtijd van het event EventEndTime	De timestamp die aangeeft wanneer een activiteit met een bepaalde duur werd afgerond.
Omschrijving Hoewel veel activiteiten direct zijn, kunnen sommige, zoals 'Beleidscheck Uitgevoerd', een meetbare duur hebben. Dit attribuut legt de eindtijd van dergelijke activiteiten vast, als aanvulling op de StartTime. Het hebben van zowel een start- als een eindtijd maakt een precieze berekening van de verwerkingstijden van activiteiten mogelijk. Dit is essentieel voor KPI's zoals 'Gemiddelde Duur Beleidscheck' en voor het exact identificeren van hoe lang specifieke geautomatiseerde of handmatige taken duren binnen het gehele proces. Het belang Het maakt de precieze berekening van individuele `activity durations` mogelijk, wat cruciaal is voor het identificeren van inefficiënte `process steps`. Vindplaats Voor `activities` met een `duration` zou dit `gelogd` worden in Ramp's `event data`. Voor `instantaneous events` kan het hetzelfde zijn als de `StartTime`. Voorbeelden 2023-10-26T10:00:05Z2023-10-26T14:35:10Z2023-10-27T09:10:00Z
	Goedkeurende `Manager` ApprovingManager	De naam van de manager die de goedkeuringsstap heeft uitgevoerd.
Omschrijving Dit attribuut identificeert de manager die verantwoordelijk is voor het beoordelen en goedkeuren van het onkostenrapport van een medewerker. Het is onderscheiden van de gebruiker die het rapport heeft ingediend. Het volgen van de goedkeurende manager is essentieel voor het 'Manager Goedkeuringsdoorlooptijd' dashboard. Het maakt analyse van goedkeuringswerklasten en prestaties mogelijk, waarbij managers die snel goedkeuren worden benadrukt versus degenen die knelpunten vormen. Dit kan helpen bij het balanceren van werklasten of het bieden van aanvullende ondersteuning. Het belang Het maakt `performance analysis` mogelijk van individuele `approvers`, wat helpt bij het identificeren en aanpakken van `bottlenecks` in de `approval workflow`. Vindplaats Deze informatie maakt deel uit van de goedkeurings workflow data in Ramp, vastgelegd wanneer een manager actie onderneemt op een rapport. Voorbeelden Jane DoeJohn MillerSusan Chen
	Indieningsmethode SubmissionMethod	Het kanaal via welke het onkostenrapport werd ingediend, zoals een mobiele app of webportaal.
Omschrijving Dit attribuut geeft aan hoe de medewerker zijn onkostenrapport heeft ingediend. Gangbare methoden zijn onder meer het gebruik van een mobiele applicatie, een desktop webbrowser of het doorsturen van e-mail. Het analyseren van de indieningsmethode kan inzichten bieden in gebruikersgedrag en technologieadoptie. Een hoog percentage revisies voor rapporten die via een bepaald kanaal zijn ingediend, kan bijvoorbeeld wijzen op bruikbaarheidsproblemen met de interface van dat kanaal. Het belang Het biedt `context` over `user behavior` en kan helpen identificeren of bepaalde `submission channels` geassocieerd zijn met hogere `error rates` of `vertragingen`. Vindplaats Deze informatie kan worden vastgelegd in de metadata van de indieningsgebeurtenis in de systeemlogs van Ramp. Voorbeelden Mobiele appWebportaalE-mail
	Is herstelwerk IsRework	Een berekende `flag` die aangeeft of een `declaratie` ten minste één keer is teruggestuurd voor `revisie`.
Omschrijving Dit booleaanse attribuut wordt afgeleid door te controleren of de activiteit 'Uitgave teruggestuurd voor revisie' heeft plaatsgevonden voor een bepaalde case. Het wordt op 'true' gezet voor elk rapport dat ten minste één revisiecyclus heeft doorlopen. Deze vlag vereenvoudigt de berekening van de KPI 'Revisiepercentage Onkostenrapport' en maakt het eenvoudig om te filteren en te vergelijken tussen rapporten die bij de eerste indiening zijn goedgekeurd en rapporten die herstelwerk vereisten. Het analyseren van deze twee cohorten kan de tijd- en kostenimpact van revisies onthullen. Het belang Het segmenteert gemakkelijk het `proces` voor `rework analysis`, wat helpt bij het kwantificeren van de frequentie en `impact` van `rapporten` die worden teruggestuurd voor correctie. Vindplaats Dit is een berekend veld, afgeleid tijdens data transformatie door te controleren op het bestaan van een revisieactiviteit binnen de case. Voorbeelden truefalse
	Laatste data-update LastDataUpdate	De `timestamp` die de laatste keer aangeeft dat de `data` is ververst vanuit het bronsysteem.
Omschrijving Dit attribuut registreert de datum en tijd van de meest recente data-extractie. Het biedt context over de versheid van de geanalyseerde data. In elke analyse is het cruciaal om de recentheid van de data te kennen voor een correcte interpretatie van de resultaten. Dit attribuut helpt gebruikers te begrijpen of zij naar actuele informatie kijken. Het belang Het informeert `users` over de tijdigheid van de `data`, zodat `analyses` gebaseerd zijn op actuele en relevante `informatie`. Vindplaats Deze timestamp wordt gegenereerd en toegevoegd tijdens het data-extractieproces. Voorbeelden 2023-11-01T06:00:00Z
	Totale Vergoedingsdoorlooptijd TotalReimbursementCycleTime	De totale verstreken tijd vanaf het moment dat een onkostenrapport werd ingediend tot het moment dat de vergoeding werd uitgevoerd.
Omschrijving Deze berekende metric meet de end-to-end duur van het vergoedingsproces vanuit het perspectief van de medewerker. Het wordt berekend als het tijdsverschil tussen de gebeurtenissen 'Uitgave Ingediend' en 'Vergoeding Uitgevoerd' voor elke case. Dit attribuut vormt de basis voor de KPI 'Gemiddelde Vergoedingsdoorlooptijd' en het 'End-to-End Vergoedingscyclus' dashboard. Het biedt een high-level maatstaf voor procesefficiëntie en is een belangrijke indicator van medewerkerstevredenheid. Het belang Het kwantificeert de algehele `process duration`, wat een `key performance indicator` biedt voor het meten van `end-to-end efficiency`. Vindplaats Dit wordt berekend tijdens data transformatie door de timestamp van de eerste indieningsgebeurtenis af te trekken van de definitieve vergoedingsgebeurtenis. Voorbeelden 3 dagen en 4 uur10 dagen 1 uur1 dag 8 uur
	Vergoedingsmethode ReimbursementMethod	De methode die wordt gebruikt om de vergoedingsbetaling uit te voeren, zoals ACH of bankoverschrijving.
Omschrijving Dit attribuut specificeert het betalingskanaal via welk de medewerker werd vergoed. Verschillende methoden kunnen verschillende verwerkingstijden en kosten met zich meebrengen. Het analyseren van de vergoedingsprestaties per methode helpt bij het identificeren van de meest efficiënte betalingskanalen. Het 'Vergoedingsmethode Prestatie' dashboard gebruikt deze data om doorlooptijden en betrouwbaarheid te vergelijken, wat potentieel kan leiden tot de optimalisatie van betalingsstrategieën. Het belang Het maakt `performance comparison` mogelijk tussen verschillende `payment channels`, wat helpt bij het optimaliseren voor snelheid en betrouwbaarheid. Vindplaats Deze informatie moet beschikbaar zijn in de betalings- of vergoedingsrecords binnen Ramp. Voorbeelden ACH TransferZakelijke Creditcard `Credit`Direct Deposit

Verplicht Aanbevolen Optioneel

`Expense Management Activities`

Dit zijn de belangrijkste processtappen en mijlpalen om vast te leggen in uw event log voor nauwkeurige process discovery en prestatiemeting.

5 Aanbevolen 7 Optioneel

	Activiteit	Omschrijving
	`Uitgave` Gemaakt	Markeert de creatie van een uitgave, meestal automatisch geïnitieerd wanneer een bedrijfscreditcard wordt gebruikt of wanneer een medewerker handmatig een out-of-pocket onkostenpost aanmaakt. Deze gebeurtenis wordt meestal vastgelegd uit transactie data feeds of gebruikersinterfaceacties.
Het belang Dit is de primaire startgebeurtenis voor de levenscyclus van de uitgave. Het analyseren van de tijd vanaf deze gebeurtenis helpt bij het begrijpen van indieningsvertragingen en de algehele processnelheid. Vindplaats `Gegenereerd` vanuit Ramp `card transaction logs` of de `creation timestamp` van een handmatig ingevoerd `expense object`. Zoek naar de initiële `record creation event` in de `expense` of `transaction table`. Vastleggen Direct `gelogd` wanneer een `kaarttransactie` wordt verwerkt of een `user` een nieuwe `expense entry` aanmaakt. Gebeurtenistype explicit
	`Uitgave` Ingediend	Een `werknemer` bevestigt dat alle benodigde `informatie` voor een `uitgave` compleet is en dient deze in voor het `approval process`. Dit is een expliciete `user action` die de `uitgave` verplaatst van een 'draft' of 'needs attention' `state` naar een 'pending approval' `state`.
Het belang Deze activiteit is een cruciale mijlpaal die officieel de goedkeurings- en vergoedingscyclus start. Het is de basis voor het meten van goedkeurings- en vergoedings-SLA's. Vindplaats Vastgelegd vanuit de `status history` van het `expense object`. Dit komt overeen met de `user action` van het indienen van de `transactie` ter `review`. Vastleggen `Gelogd` wanneer de `user` op de 'Submit'-knop klikt, wat een `status change` triggert. Gebeurtenistype explicit
	Door manager goedgekeurd	De manager heeft de uitgave beoordeeld en goedgekeurd, waardoor deze kan doorgaan naar de volgende stap, zoals financiële controle of vergoeding. Dit wordt vastgelegd via een expliciete gebruikersactie.
Het belang Dit is een belangrijke mijlpaal die de succesvolle voltooiing van het eerste goedkeuringsniveau aangeeft. Het is cruciaal voor het analyseren van goedkeuringsworkflows en het identificeren van knelpunten. Vindplaats Vastgelegd als een gebeurtenis in de goedkeuringshistorie van de onkostenpost wanneer de manager op 'Goedkeuren' klikt. Het event log moet de ID van de goedkeurder en een timestamp bevatten. Vastleggen Een `event` wordt `gelogd` bij de 'Approve' `action` door een `user` met `manager permissions`. Gebeurtenistype explicit
	Gesynchroniseerd met Boekhoudsysteem	De uitgave transactie data is succesvol geboekt naar het geïntegreerde boekhoudsysteem, zoals NetSuite, QuickBooks of Xero. Deze gebeurtenis markeert de voltooiing van het financiële boekhoudkundige deel van het proces.
Het belang Dit is de laatste activiteit in het end-to-end proces. Vertragingen hier kunnen de nauwkeurigheid van de financiële rapportage en de snelheid van de financiële afsluiting beïnvloeden. Vindplaats Vastgelegd in een integratie log of als een statusupdate van het uitgave object in Ramp. Zoek naar een status zoals 'Gesynchroniseerd', 'Geboekt' of 'Geëxporteerd'. Vastleggen Een `log entry` wordt aangemaakt door de `accounting integration service` na succesvolle `data synchronization`. Gebeurtenistype explicit
	Vergoeding Uitgevoerd	De vergoedingsbetaling is succesvol verwerkt en naar de medewerker gestuurd. Dit is doorgaans de laatste stap voor de medewerker en markeert het einde van de betalingscyclus.
Het belang Dit is de primaire eindgebeurtenis voor het vergoedingsproces. De duur van indiening tot dit punt is een kritieke KPI voor medewerkerstevredenheid en procesefficiëntie. Vindplaats Vastgelegd vanuit `payment processing logs` of een `integratie` met de `payment provider`. De `expense status` in Ramp zou worden bijgewerkt naar 'Reimbursed' of 'Paid'. Vastleggen Een `event` wordt `gelogd` wanneer het `payment system` een succesvolle `payment transfer` bevestigt. Gebeurtenistype explicit
	`Finance Review` Wachtend	Een goedgekeurde `uitgave` is `geëscaleerd` en wacht nu op `review` van het `finance` of `accounting team`. Dit gebeurt doorgaans bij `high-value expenses` of `uitgaven` met `policy flags`. De `activity` wordt afgeleid van een `status change`.
Het belang Markeert het begin van de financiële beoordelingscyclus. Het meten van de duur van deze fase helpt bij het beoordelen van de werklast en efficiëntie van het finance team, en identificeert kansen voor automatisering. Vindplaats Afgeleid van een `status change` op het `expense object` naar 'Pending Finance Approval' na `manager approval`. Dit vereist toegang tot de `status history` van de `uitgave`. Vastleggen Afgeleid van de `timestamp` wanneer de `expense status` wordt bijgewerkt naar 'Pending Finance Review'. Gebeurtenistype inferred
	`Finance` Goedgekeurd	Het finance team heeft de uitgave beoordeeld en definitief goedgekeurd, waardoor deze klaar is voor vergoeding en synchronisatie met de boekhouding. Dit wordt vastgelegd als een expliciete gebruikersactie door een lid van het finance team.
Het belang Vertegenwoordigt de laatste goedkeuringsstap vóór betaling. Het analyseren van deze activiteit helpt bij het begrijpen van de end-to-end goedkeuringscyclus en de efficiëntie van het finance team. Vindplaats `Gelogd` als een `event` in de `approval history` van de `uitgave`. Zoek naar een `approval event` geassocieerd met een `user` van de `finance afdeling`. Vastleggen Een `event` wordt `gelogd` bij de 'Approve' `action` door een `user` met `finance permissions`. Gebeurtenistype explicit
	`Manager Review` Wachtend	De uitgave is ingediend en wacht nu op beoordeling door de directe manager van de medewerker. Deze status wordt afgeleid wanneer de uitgave status verandert naar 'Wachtend op Goedkeuring Manager' of een vergelijkbare waarde na indiening.
Het belang Identificeert het begin van de `manager approval stage`. Het analyseren van de tijd besteed in deze `state` is essentieel voor het meten en verbeteren van `manager approval cycle times`. Vindplaats Afgeleid van een `status change` op het `expense object` naar een `state` zoals 'Pending Approval' en toewijzing aan de `queue` van een `manager`. Vereist het volgen van `status history`. Vastleggen Afgeleid van de `timestamp` wanneer de `expense status` 'Pending Manager Approval' wordt. Gebeurtenistype inferred
	`Uitgave` Teruggestuurd voor `Revisie`	Een `approver`, ofwel een `manager` of `finance reviewer`, heeft de `uitgave` afgewezen en teruggestuurd naar de `werknemer` voor correctie. Dit wordt vastgelegd door een `status change` naar een 'Needs Revision' of 'Rejected' `state`.
Het belang Deze activiteit duidt op een herwerkingslus in het proces, wat direct de doorlooptijd verlengt. Het volgen van deze gebeurtenissen helpt bij het identificeren van veelvoorkomende indieningsfouten en het verbeteren van de 'first-pass yield'. Vindplaats Afgeleid van een `status change` op het `expense object` naar 'Needs Revision' of een vergelijkbare `state`. Het `event` moet gekoppeld zijn aan de `approver` die de `action` heeft geïnitieerd. Vastleggen Afgeleid van de `timestamp` wanneer de `expense status` 'Needs Revision' of 'Rejected' wordt. Gebeurtenistype inferred
	Beleidscheck Uitgevoerd	Het systeem controleert automatisch de uitgave aan de hand van geconfigureerde bedrijfsbeleidsregels en markeert mogelijke overtredingen. Dit is doorgaans een door het systeem gegenereerde gebeurtenis die kort na indiening plaatsvindt.
Het belang Meet de efficiëntie van geautomatiseerde compliance checks en hun impact op het proces. Helpt bij het identificeren van veelvoorkomende beleidsschendingen en gebieden voor training van medewerkers. Vindplaats Waarschijnlijk vastgelegd in een `audit trail` of `log` geassocieerd met de `expense transaction`. Zoek naar `system events` gerelateerd aan 'policy_check' of 'compliance_scan'. Vastleggen Een `system log entry` wordt aangemaakt nadat de `automated policy engine` op de `transactie` is uitgevoerd. Gebeurtenistype explicit
	Bon Bijgevoegd	Vertegenwoordigt het moment dat een bon wordt gekoppeld aan een uitgave, hetzij automatisch via OCR-matching of handmatig door de gebruiker. Dit wordt vastgelegd wanneer het bonbestand succesvol is gekoppeld aan de transactierecord.
Het belang Het volgen van deze activiteit helpt bij het identificeren van vertragingen veroorzaakt door ontbrekende documentatie. Het is een cruciale stap om compliance en auditbereidheid te waarborgen. Vindplaats `Gelogd` in de `expense` of `transaction history` wanneer een `bon` wordt `geüpload` of `gematcht`. Controleer op een `attachment creation event` of een `flag` die 'receipt_attached' aangeeft. Vastleggen `Event` wordt aangemaakt wanneer het `systeem` een `bonafbeelding` of -bestand koppelt aan de `expense record`. Gebeurtenistype explicit
	Vergoeding Ingepland	Voor `out-of-pocket expenses` is het goedgekeurde bedrag in de `queue` geplaatst voor `payment processing`. Dit `event` geeft aan dat de `uitgave` alle `approvals` heeft doorlopen en klaar is om te worden uitbetaald.
Het belang Deze mijlpaal scheidt het goedkeuringsproces van het betaaluitvoeringsproces. Het helpt vertragingen te isoleren die optreden bij de betalingsverwerking versus die bij de goedkeuringen. Vindplaats Waarschijnlijk afgeleid van de `expense status` die verandert naar 'Pending Reimbursement' of 'Ready for Payment' na definitieve `approval`. Kan ook een expliciet `event` zijn als `payments` in `batches` worden verwerkt. Vastleggen Afgeleid van een `status change` naar 'Ready for Payout' of van de aanmaak van een `record` in een `payment batch table`. Gebeurtenistype inferred

Aanbevolen Optioneel

Extractie Guides

Hoe u uw `data` uit Ramp krijgt

Stappen

Log in op uw Ramp-account met Admin- of Bookkeeper-rechten.
Navigeer naar de sectie Transactions vanuit het linkermenu. Deze weergave bevat alle uitgaven van zakelijke kaarten.
Pas de gewenste filters toe op de data. Stel minimaal een Datumbereik in voor de periode die u wilt analyseren. U kunt ook filteren op andere properties zoals Status, Category of Department om de scope te verfijnen indien nodig.
Klik op de Export-knop rechtsboven in de transactielijst.
In de exportmodal selecteert u Transactions als het exporttype en CSV als het formaat. Download het bestand en noem het transactions_export.csv.
Navigeer vervolgens naar de sectie Reimbursements vanuit het linkermenu. Deze weergave bevat alle out-of-pocket expenses die door werknemers zijn ingediend.
Pas hetzelfde datumbereikfilter toe als gebruikt voor de transaction export om dataconsistentie te waarborgen.
Klik op de Export-knop en download de reimbursements data als een CSV-bestand. Noem dit bestand reimbursements_export.csv.
Plaats beide geëxporteerde CSV-bestanden (transactions_export.csv en reimbursements_export.csv) in dezelfde map als het meegeleverde Python script.
Voer het Python script uit. Het script zal beide bestanden laden, de data transformeren door een afzonderlijke rij voor elke business event aan te maken, en deze samenvoegen tot een enkel, gestructureerd event log.
Het script zal een bestand met de naam ramp_event_log.csv uitvoeren. Dit bestand is geformatteerd volgens de ProcessMind requirements.
Upload het ramp_event_log.csv-bestand naar ProcessMind voor analyse.

Configuratie

Permissions: U moet 'Admin' of 'Bookkeeper' rollen in Ramp hebben om toegang te krijgen tot en de complete transactie- en declaratie datasets te exporteren.
Datumbereik: Voor een initiële analyse, selecteer een datumbereik van minimaal 6 tot 12 maanden om voldoende procesvariaties vast te leggen. Voor continue monitoring kunt u een korter, recenter bereik gebruiken.
Dataconsistentie: Zorg ervoor dat u exact hetzelfde datumbereik en dezelfde filters gebruikt bij het exporteren van zowel de Transactions- als de Reimbursements-bestanden om een consistente dataset te behouden.
Exportformaat: Kies altijd het CSV-formaat voor beide exports, aangezien het transformatiescript is ontworpen om komma-gescheiden bestanden te verwerken.
Bestandsnaamgeving: Houd u aan de bestandsnamen transactions_export.csv en reimbursements_export.csv of update de bestandspadvariabelen in het transformatiescript dienovereenkomstig.

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

Stappen

Vereisten en Omgevingsinstelling: Zorg ervoor dat u Python 3.8 of nieuwer heeft geïnstalleerd. Installeer de benodigde Python libraries door pip install requests pandas uit te voeren. U moet ook administrator toegang hebben tot uw Ramp-instantie om API credentials te genereren.
Genereer Ramp API Credentials: Log in op uw Ramp account. Navigeer naar Settings, en selecteer vervolgens Developer API in het zijmenu. Klik op 'Create App', geef uw applicatie een naam, en configureer de vereiste scopes. U heeft transactions:read, reimbursements:read en users:read nodig. Eenmaal gemaakt, kopieert u veilig de Client ID en Client Secret.
Configureer het Python-Script: Maak een nieuw Python-bestand, bijvoorbeeld extract_ramp_log.py. Kopieer het geleverde Python script in dit bestand. Stel uw Client ID en Client Secret in als environment variables of direct in het script voor testdoeleinden. Het wordt sterk aanbevolen om environment variables te gebruiken voor security.
Stel het Extractie Datumbereik in: Zoek in het script de START_DATE en END_DATE variables binnen het main execution block. Pas deze datums aan om het tijdsvenster voor de data extraction te definiëren. Een periode van 3 tot 6 maanden wordt aanbevolen voor een initiële analyse.
Voer het Script Uit: Voer het script uit vanuit uw terminal met het commando python extract_ramp_log.py. Het script zal authentiseren met de Ramp API, data ophalen van de users, transactions en reimbursements endpoints, en paginering automatisch afhandelen.
Begrijp de API Calls: Het script haalt eerst alle user data op om een mapping te maken van user IDs naar namen en afdelingen. Vervolgens haalt het alle reimbursements op binnen het opgegeven datumbereik. Voor elke declaratie extraheert het de approval en payment history.
Transformeer Data naar een Event Log: De kernlogica van het script itereert door elke declaratie en de bijbehorende state history. Het vertaalt elke state change, zoals 'MANAGER_APPROVAL' of 'FINISHED', naar een afzonderlijke activity zoals 'Manager Review Pending' of 'Reimbursement Executed'. Het haalt ook bijbehorende transaction data op om 'Expense Incurred' en 'Receipt Attached' events te creëren.
Beheer Data Enrichment: Het script verrijkt de event log door user details, department information en expense category voor elk event toe te voegen, waardoor een uitgebreide dataset voor process analysis wordt gecreëerd.
Controleer de Uitvoer: Zodra het script is voltooid, genereert het een bestand met de naam ramp_event_log.csv in dezelfde map. Open dit CSV-bestand in een spreadsheetprogramma om de data te inspecteren en ervoor te zorgen dat deze naar verwachting is geëxtraheerd.
Bereid voor op Upload: Het gegenereerde CSV-bestand is gestructureerd met de vereiste columns: ExpenseReportId, ActivityName, EventTimestamp, en andere aanbevolen attributes. Dit bestand is klaar voor directe upload naar het ProcessMind platform.

Configuratie

API Credentials: Een geldige Client ID en Client Secret zijn vereist voor authenticatie. Deze worden gegenereerd binnen het Ramp dashboard onder Settings > Developer API.
API Scopes: Het script vereist specifieke permissions om data te openen. Zorg ervoor dat de volgende scopes zijn ingeschakeld voor uw API key: transactions:read (voor expense en receipt details), reimbursements:read (voor indiening, approval en payment status), en users:read (voor werknemersnaam en afdeling).
Datumbereik: De extractie wordt bepaald door START_DATE en END_DATE parameters in het script. Het wordt aanbevolen om te starten met een recente periode, zoals de laatste 3-6 maanden, om de initiële dataset beheersbaar te houden. De filter wordt toegepast op de aanmaakdatum van de declaratie.
Paginering: Het script verwerkt automatisch API pagination met behulp van de starting_after cursor die door de Ramp API wordt geleverd. Het haalt records op in batches (tot 100 per request) om te zorgen dat alle data binnen het datumbereik wordt opgehaald.
Rate Limiting: De Ramp API is onderhevig aan rate limits, doorgaans 600 requests per minuut. Het meegeleverde script is over het algemeen efficiënt, maar voor extreem grote datasets moet u mogelijk kleine vertragingen tussen API calls introduceren als u rate limit errors tegenkomt.

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

Stappen

Log in op uw Ramp-account met Admin- of Bookkeeper-rechten.
Navigeer naar de sectie Transactions vanuit het linkermenu. Deze weergave bevat alle uitgaven van zakelijke kaarten.
Pas de gewenste filters toe op de data. Stel minimaal een Datumbereik in voor de periode die u wilt analyseren. U kunt ook filteren op andere properties zoals Status, Category of Department om de scope te verfijnen indien nodig.
Klik op de Export-knop rechtsboven in de transactielijst.
In de exportmodal selecteert u Transactions als het exporttype en CSV als het formaat. Download het bestand en noem het transactions_export.csv.
Navigeer vervolgens naar de sectie Reimbursements vanuit het linkermenu. Deze weergave bevat alle out-of-pocket expenses die door werknemers zijn ingediend.
Pas hetzelfde datumbereikfilter toe als gebruikt voor de transaction export om dataconsistentie te waarborgen.
Klik op de Export-knop en download de reimbursements data als een CSV-bestand. Noem dit bestand reimbursements_export.csv.
Plaats beide geëxporteerde CSV-bestanden (transactions_export.csv en reimbursements_export.csv) in dezelfde map als het meegeleverde Python script.
Voer het Python script uit. Het script zal beide bestanden laden, de data transformeren door een afzonderlijke rij voor elke business event aan te maken, en deze samenvoegen tot een enkel, gestructureerd event log.
Het script zal een bestand met de naam ramp_event_log.csv uitvoeren. Dit bestand is geformatteerd volgens de ProcessMind requirements.
Upload het ramp_event_log.csv-bestand naar ProcessMind voor analyse.

Configuratie

Permissions: U moet 'Admin' of 'Bookkeeper' rollen in Ramp hebben om toegang te krijgen tot en de complete transactie- en declaratie datasets te exporteren.
Datumbereik: Voor een initiële analyse, selecteer een datumbereik van minimaal 6 tot 12 maanden om voldoende procesvariaties vast te leggen. Voor continue monitoring kunt u een korter, recenter bereik gebruiken.
Dataconsistentie: Zorg ervoor dat u exact hetzelfde datumbereik en dezelfde filters gebruikt bij het exporteren van zowel de Transactions- als de Reimbursements-bestanden om een consistente dataset te behouden.
Exportformaat: Kies altijd het CSV-formaat voor beide exports, aangezien het transformatiescript is ontworpen om komma-gescheiden bestanden te verwerken.
Bestandsnaamgeving: Houd u aan de bestandsnamen transactions_export.csv en reimbursements_export.csv of update de bestandspadvariabelen in het transformatiescript dienovereenkomstig.

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

Uw template voor onkostenbeheer data

Uw template voor onkostenbeheer data

`Expense Management Attributes`

`Expense Management Activities`

Extractie Guides

Ramp Ingebouwde CSV Transactie- en Vergoedings export

Stappen

Configuratie

a Voorbeeldquery config

Python Script Extractie via de Ramp Developer API

Stappen

Configuratie

a Voorbeeldquery python

Ramp Data Warehouse Integratie Sync (Snowflake/BigQuery)

Stappen

Configuratie

a Voorbeeldquery config

Klaar om te starten?

Ontgrendel Efficiëntie: Optimaliseer Ramp Onkostenbeheer Vandaag

Uw template voor onkostenbeheer data

Uw template voor onkostenbeheer data

Expense Management Attributes

Expense Management Activities

Extractie Guides

Ramp Ingebouwde CSV Transactie- en Vergoedings export

Stappen

Configuratie

a Voorbeeldquery config

Python Script Extractie via de Ramp Developer API

Stappen

Configuratie

a Voorbeeldquery python

Ramp Data Warehouse Integratie Sync (Snowflake/BigQuery)

Stappen

Configuratie

a Voorbeeldquery config

Wij hechten veel waarde aan je privacy

Klaar om te starten?

Ontgrendel Efficiëntie: Optimaliseer Ramp Onkostenbeheer Vandaag

`Expense Management Attributes`

`Expense Management Activities`