> Ciągłe doskonalenie procesów > Zarządzanie wydatkami > Ramp > Szablon danych

Szablon danych dotyczących zarządzania wydatkami

Ramp

← Wróć do przewodnika ulepszania procesów

Atrybuty procesu zarządzania wydatkami(19) Czynności w procesie zarządzania wydatkami(12) Instrukcje eksportu danych(3)

Szablon danych dotyczących zarządzania wydatkami

Szablon zawiera wskazówki dotyczące zbierania danych potrzebnych do analizy i usprawnienia procesu zarządzania wydatkami. Wymienia niezbędne atrybuty, czynności do śledzenia oraz praktyczne sposoby eksportowania danych z Ramp. Dzięki niemu można zgromadzić informacje potrzebne do analizy i ulepszania procesów.

Zalecane atrybuty do zebrania
Czynności do śledzenia
Wskazówki dotyczące eksportu danych z Ramp

Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Pobierz szablon

Atrybuty procesu zarządzania wydatkami

To podstawowe pola danych, które należy uwzględnić w dzienniku zdarzeń, aby dokładnie przeanalizować proces zarządzania wydatkami.

3 Wymagane 6 Zalecane 10 Opcjonalne

	Nazwa	Opis
	Identyfikator raportu wydatków ExpenseReportId	Unikalny identyfikator każdego raportu wydatków, który służy jako główny identyfikator sprawy w procesie.
Opis Identyfikator raportu wydatków grupuje wszystkie zdarzenia i działania związane z jednym zgłoszeniem wydatków. Umożliwia pełne śledzenie roszczenia chronologicznie, od pierwszego wpisu do ostatecznej płatności. W process mining ten atrybut jest niezbędny do odtworzenia całego przebiegu każdego raportu wydatków. Użycie go jako identyfikatora sprawy pozwala dokładnie obliczać czas procesu, wykrywać wąskie gardła i wizualizować różne ścieżki raportów w procesie akceptacji. Dlaczego to ważne To podstawowy atrybut łączący wszystkie powiązane działania w jedną instancję procesu i umożliwiający analizę całego przebiegu. Skąd pobrać Ten identyfikator powinien być dostępny w głównej tabeli raportów wydatków lub transakcji w Ramp. Przykłady ER-2023-08-1123ER-2023-09-4591ER-2023-10-0024
	Nazwa działania ActivityName	Nazwa konkretnego zdarzenia lub zadania, które wystąpiło w określonym momencie procesu zarządzania wydatkami.
Opis Ten atrybut opisuje pojedynczy etap cyklu obsługi raportu wydatków, na przykład „Zgłoszenie wydatku”, „Akceptacja przez menedżera” lub „Realizacja zwrotu wydatku”. Działania te tworzą węzły mapy procesu, dzięki czemu można wizualizować i analizować jego przebieg. Analiza działań pomaga ustalić, które etapy występują najczęściej, gdzie pojawiają się wąskie gardła i czym różnią się poszczególne workflow. To podstawowy element pozwalający zrozumieć kolejność operacji i mierzyć wyniki na każdym etapie. Dlaczego to ważne Określa etapy na mapie procesu, umożliwiając wizualizację i analizę jego przebiegu od początku do końca. Skąd pobrać Zwykle jest ustalana na podstawie dzienników zdarzeń lub zapisów zmian statusu powiązanych z każdym raportem wydatków w Ramp. Przykłady Zgłoszenie wydatkuAkceptacja przez menedżeraOczekiwanie na weryfikację finansowąRealizacja zwrotu wydatku
	Znacznik czasu zdarzenia EventTimestamp	Dokładna data i godzina wystąpienia działania.
Opis Każde działanie w procesie ma przypisany znacznik czasu, który określa, kiedy do niego doszło. Dane czasowe służą do uporządkowania zdarzeń chronologicznie i stanowią podstawę wszystkich analiz czasu. W process mining znaczniki czasu pozwalają obliczać czas między działaniami, mierzyć całkowity czas obsługi sprawy i wykrywać opóźnienia. Informacje te są niezbędne do monitorowania wyników i wskazywania możliwości usprawnienia procesu. Dlaczego to ważne Atrybut ten określa chronologiczną kolejność zdarzeń i jest niezbędny do obliczania czasu trwania oraz analizy wyników. Skąd pobrać Te informacje znajdują się zwykle przy zapisach działań lub statusów w dziennikach zdarzeń Ramp albo w danych transakcyjnych. Przykłady 2023-10-26T10:00:00Z2023-10-26T14:30:00Z2023-10-27T09:00:00Z
	Dział pracownika EmployeeDepartment	Dział pracownika, który zgłosił raport wydatków.
Opis Ten atrybut wskazuje jednostkę biznesową lub dział, do którego należy pracownik zgłaszający wydatek, na przykład „Sprzedaż”, „Inżynieria” lub „Marketing”. To ważny wymiar analizy, który pozwala filtrować i porównywać wyniki procesu w różnych częściach organizacji. Może ujawnić różnice między działami w czasie akceptacji, odsetku raportów wymagających poprawy i zgodności z zasadami, co ułatwia planowanie ukierunkowanych usprawnień. Dlaczego to ważne Umożliwia porównywanie wskaźników procesu między jednostkami biznesowymi i wskazywanie różnic w sprawności, zgodności z zasadami oraz wydatkach. Skąd pobrać Informacje te są prawdopodobnie zapisane w profilu użytkownika w Ramp lub w zintegrowanym systemie HR. Przykłady SprzedażMarketingInżynieriaFinanse
	Flaga naruszenia zasad PolicyViolationFlag	Flaga wskazująca, czy raport wydatków został oznaczony jako potencjalne naruszenie zasad.
Opis Ten atrybut logiczny przyjmuje wartość true, jeśli automatyczne kontrole systemu wykryją potencjalne naruszenie firmowych zasad dotyczących wydatków, na przykład przekroczenie limitu lub zgłoszenie zduplikowanego wydatku. Flaga ta jest niezbędna w dashboardzie „Wykrywanie naruszeń zasad” i powiązanym z nim KPI. Pomaga mierzyć skuteczność kontroli oraz wykrywać częste przypadki niezgodności, co może stanowić podstawę do aktualizacji zasad lub szkoleń dla pracowników. Dlaczego to ważne Bezpośrednio mierzy zgodność z zasadami, pomagając wykrywać i ograniczać wydatki niezgodne z nimi oraz związane z tym ryzyko. Skąd pobrać Prawdopodobnie jest to flaga generowana przez system Ramp po automatycznej kontroli zasad podczas zgłaszania lub akceptacji wydatku. Przykłady truefalse
	Kategoria wydatku ExpenseCategory	Kategoria przypisana do wydatku, na przykład „Podróże”, „Oprogramowanie” lub „Posiłki”.
Opis Ten atrybut przypisuje wydatki do wcześniej określonych kategorii, co ułatwia monitorowanie i kontrolowanie wydatków firmowych. Jeden raport może obejmować pozycje z kilku kategorii. Analiza według kategorii wydatków jest niezbędna w dashboardzie „Analiza kategorii wydatków”. Pomaga zespołom finansowym zrozumieć, na co przeznaczane są środki, monitorować przestrzeganie budżetu oraz wykrywać trendy i nietypowe zmiany wydatków. Dlaczego to ważne Umożliwia szczegółową analizę wydatków, wskazując główne źródła kosztów i możliwości lepszego wykorzystania budżetu. Skąd pobrać Zwykle są to szczegółowe dane dotyczące poszczególnych pozycji raportu wydatków w Ramp. W niektórych analizach może być konieczne zagregowanie danych do poziomu raportu. Przykłady Bilety lotniczePosiłki i rozrywkaSubskrypcja oprogramowaniaMateriały biurowe
	Łączna kwota raportu ReportTotalAmount	Łączna wartość pieniężna wydatków ujętych w raporcie.
Opis Ten atrybut oznacza sumę wszystkich wydatków ujętych w jednym raporcie. Jest ważnym wskaźnikiem finansowym, który pomaga zrozumieć strukturę wydatków. W analizie procesu kwota raportu pozwala podzielić sprawy na grupy i sprawdzić, czy raporty o wysokiej wartości przechodzą inną ścieżkę akceptacji lub są przetwarzane dłużej. Jest też podstawą dashboardów do analizy wydatków i wskazywania możliwości ograniczenia kosztów. Dlaczego to ważne Dostarcza ważnego wymiaru finansowego do analizy, umożliwiając podział raportów według wartości i śledzenie łącznych wydatków. Skąd pobrać To podstawowe pole obiektu raportu wydatków w Ramp. Przykłady 150.752500.0089.99
	Nazwa użytkownika UserName	Nazwa lub identyfikator użytkownika, który wykonał działanie, na przykład pracownika zgłaszającego wydatek lub osoby go akceptującej.
Opis Ten atrybut wskazuje osobę odpowiedzialną za dane zdarzenie w procesie, na przykład zgłoszenie, akceptację lub weryfikację raportu wydatków. Może to być imię i nazwisko pracownika albo unikalny identyfikator użytkownika. Analiza według użytkownika pomaga zrozumieć rozkład obciążenia pracą, wskazać osoby osiągające dobre wyniki i ustalić, kto może potrzebować dodatkowego szkolenia. Atrybut ten jest przydatny w dashboardach dotyczących sprawności akceptacji i zarządzania zasobami. Dlaczego to ważne Pozwala przypisać działania w procesie do konkretnych osób, analizować wyniki na poziomie zasobów i wskazywać potrzeby szkoleniowe. Skąd pobrać Informacje o użytkowniku są zwykle zapisywane w ścieżce audytu lub historii transakcji każdego raportu wydatków w Ramp. Przykłady Alice JohnsonBob SmithCharlie BrownAutomatyzacja systemowa
	Powód odesłania do poprawy RevisionReason	Powód podany przy odesłaniu raportu wydatków pracownikowi do poprawy.
Opis Gdy osoba akceptująca odrzuca raport wydatków lub odsyła go do poprawy, zwykle podaje powód, na przykład „Brak szczegółowego paragonu”, „Nieprawidłowa kategoria” lub „Wydatek niezgodny z zasadami”. Ten atrybut zapisuje podaną przyczynę. Informacje te są bardzo przydatne w dashboardzie „Odsetek raportów wymagających poprawy i przyczyny”. Analiza najczęstszych powodów poprawek pozwala wykrywać problemy systemowe w procesie zgłaszania i wdrażać ukierunkowane szkolenia lub usprawnienia systemu, aby ograniczyć liczbę błędów. Dlaczego to ważne Pokazuje bezpośrednio przyczyny konieczności ponownej pracy, co pozwala podejmować ukierunkowane działania i poprawiać jakość zgłoszeń już za pierwszym razem. Skąd pobrać Dane te są zapisywane w komentarzach lub szczegółach odrzucenia, gdy w Ramp wystąpi działanie „Odesłanie wydatku do poprawy”. Przykłady Brak szczegółowego paragonuWydatek przekracza limit określony w zasadachWybrano nieprawidłową kategorię wydatkuZduplikowana transakcja
	Czas zakończenia zdarzenia EventEndTime	Znacznik czasu wskazujący, kiedy zakończyła się czynność o określonym czasie trwania.
Opis Wiele czynności odbywa się natychmiast, ale niektóre, na przykład „Przeprowadzono kontrolę zgodności z polityką”, mogą trwać określony czas. Ten atrybut zapisuje czas zakończenia takich czynności i uzupełnia wartość StartTime. Zapisanie czasu rozpoczęcia i zakończenia pozwala dokładnie obliczyć czas realizacji czynności. Jest to niezbędne do wyznaczania KPI, takich jak „Średni czas kontroli zgodności z polityką”, oraz ustalenia, ile dokładnie trwają poszczególne zadania automatyczne i ręczne w całym procesie. Dlaczego to ważne Umożliwia dokładne obliczenie czasu trwania poszczególnych czynności, co pomaga wykrywać nieefektywne etapy procesu. Skąd pobrać Czas zakończenia czynności o określonym czasie trwania byłby zapisany w danych zdarzeń Ramp. W przypadku zdarzeń natychmiastowych może być taki sam jak StartTime. Przykłady 2023-10-26T10:00:05Z2023-10-26T14:35:10Z2023-10-27T09:10:00Z
	Czy wymaga poprawek IsRework	Obliczany wskaźnik informujący, czy raport wydatków został co najmniej raz odesłany do poprawy.
Opis Ten atrybut logiczny jest wyznaczany na podstawie tego, czy w danym case wystąpiła czynność „Odesłano raport wydatków do poprawy”. Wartość true otrzymuje każdy raport, który przeszedł co najmniej jeden cykl poprawek. Wskaźnik ułatwia obliczenie KPI „Odsetek raportów wydatków wymagających poprawek” oraz filtrowanie i porównywanie raportów zatwierdzonych za pierwszym razem z tymi, które wymagały poprawek. Analiza tych grup pozwala określić czas i koszty związane z poprawkami. Dlaczego to ważne Ułatwia wyodrębnienie przypadków wymagających poprawek i określenie, jak często raporty są odsyłane do korekty oraz jaki ma to wpływ na proces. Skąd pobrać To pole jest obliczane podczas przekształcania danych. Sprawdza się wtedy, czy w danym case wystąpiła czynność związana z poprawą raportu. Przykłady truefalse
	Data ostatniej aktualizacji danych LastDataUpdate	Znacznik czasu wskazujący, kiedy ostatnio odświeżono dane z systemu źródłowego.
Opis Ten atrybut zapisuje datę i godzinę ostatniego wyodrębnienia danych. Informuje, jak aktualne są analizowane dane. Aby prawidłowo interpretować wyniki, trzeba wiedzieć, kiedy dane zostały zebrane. Atrybut ten pozwala ocenić, czy analizowane informacje są aktualne. Dlaczego to ważne Informuje o aktualności danych, dzięki czemu analizy można opierać na bieżących i przydatnych informacjach. Skąd pobrać Ten znacznik czasu jest generowany i dodawany podczas wyodrębniania danych. Przykłady 2023-11-01T06:00:00Z
	Liczba etapów zatwierdzania ApprovalStepCount	Łączna liczba formalnych etapów zatwierdzania, przez które przeszedł raport wydatków.
Opis Ta obliczana miara zlicza różne czynności zatwierdzania, takie jak „Zatwierdzenie przez menedżera” i „Zatwierdzenie przez dział finansów”, które wystąpiły w ramach jednego raportu wydatków. Pozwala określić złożoność workflow zatwierdzania. Atrybut ten służy do obliczania KPI „Średnia liczba etapów zatwierdzania na raport” oraz tworzenia dashboardu „Proste ścieżki zatwierdzania wydatków”. Analiza liczby etapów w zestawieniu z wartością lub kategorią raportu pomaga ustalić, czy proste wydatki o niskiej wartości podlegają zbyt złożonemu procesowi zatwierdzania. Dlaczego to ważne Pozwala określić złożoność workflow i wskazać możliwości jego uproszczenia, zwłaszcza w przypadku raportów o niskim ryzyku. Skąd pobrać Wartość jest obliczana przez zliczenie w dzienniku zdarzeń wystąpień określonych czynności związanych z zatwierdzaniem w każdym case. Przykłady 123
	Menedżer akceptujący ApprovingManager	Imię i nazwisko menedżera, który wykonał etap akceptacji.
Opis Ten atrybut wskazuje menedżera odpowiedzialnego za weryfikację i akceptację raportu wydatków pracownika. Jest to inna osoba niż użytkownik, który zgłosił raport. Śledzenie menedżera akceptującego jest niezbędne w dashboardzie „Czas akceptacji przez menedżera”. Umożliwia analizę obciążenia pracą i wyników osób akceptujących oraz wskazanie menedżerów, którzy szybko akceptują raporty, i tych, którzy tworzą wąskie gardła. Dzięki temu można lepiej rozłożyć obciążenie lub zapewnić dodatkowe wsparcie. Dlaczego to ważne Umożliwia analizę wyników poszczególnych osób akceptujących oraz wykrywanie i usuwanie wąskich gardeł w workflow akceptacji. Skąd pobrać Ta informacja jest częścią danych workflow zatwierdzania w Ramp. Jest rejestrowana, gdy menedżer podejmuje działanie dotyczące raportu. Przykłady Jane DoeJohn MillerSusan Chen
	Metoda przesłania SubmissionMethod	Kanał, za pośrednictwem którego przesłano raport wydatków, na przykład aplikacja mobilna lub portal internetowy.
Opis Ten atrybut wskazuje, w jaki sposób pracownik przesłał raport wydatków. Najczęściej odbywa się to za pomocą aplikacji mobilnej, przeglądarki internetowej na komputerze lub przez przekazanie wiadomości e-mail. Analiza metody przesłania może dostarczyć informacji o zachowaniach użytkowników i wykorzystaniu technologii. Na przykład częste poprawki w raportach przesłanych określonym kanałem mogą wskazywać na problemy z obsługą tego kanału. Dlaczego to ważne Dostarcza informacji o zachowaniach użytkowników i pomaga ustalić, czy określone kanały przesyłania wiążą się z większą liczbą błędów lub opóźnień. Skąd pobrać Informacja ta może być zapisana w metadanych zdarzenia przesłania w dziennikach systemowych Ramp. Przykłady Aplikacja mobilnaPortal internetowyE-mail
	Metoda zwrotu kosztów ReimbursementMethod	Metoda realizacji zwrotu kosztów, na przykład przelew ACH lub przelew bankowy.
Opis Ten atrybut określa kanał płatności, za pośrednictwem którego pracownik otrzymał zwrot kosztów. Poszczególne metody mogą różnić się czasem realizacji i kosztami. Analiza sprawności zwrotów według metody płatności pomaga wskazać najefektywniejsze kanały. Dashboard „Skuteczność metod zwrotu kosztów” wykorzystuje te dane do porównania czasu realizacji i niezawodności, co może pomóc w optymalizacji strategii płatności. Dlaczego to ważne Umożliwia porównanie skuteczności różnych kanałów płatności i pomaga optymalizować je pod kątem szybkości oraz niezawodności. Skąd pobrać Te informacje powinny być dostępne w rejestrach płatności lub zwrotów kosztów w Ramp. Przykłady Przelew ACHZwrot na kartę firmowąPrzelew bezpośredni
	Osoba zatwierdzająca z działu finansów FinanceApprover	Użytkownik z zespołu finansowego, który zatwierdził raport wydatków.
Opis W workflow obejmującym etap weryfikacji finansowej ten atrybut wskazuje konkretną osobę lub zespół z działu finansów, który dokonał końcowego zatwierdzenia. Atrybut ten wspiera dashboard „Sprawność weryfikacji finansowej”, umożliwiając analizę wyników pracy poszczególnych osób i zespołów. Pomaga wykrywać wąskie gardła, oceniać rozkład obciążenia i mierzyć skuteczność etapu weryfikacji finansowej. Dlaczego to ważne Umożliwia szczegółową analizę etapu weryfikacji finansowej i pomaga usprawnić ważny punkt kontroli w procesie. Skąd pobrać Informacja ta byłaby zapisana w historii zatwierdzania raportu wydatków w Ramp, na etapie weryfikacji finansowej. Przykłady Zespół finansowy ADavid LeeBot automatyzujący pracę działu finansów
	System źródłowy SourceSystem	Wskazuje aplikację, z której wyodrębniono dane.
Opis Ten atrybut określa system, w którym zapisano dane o procesie, w tym przypadku Ramp. Jest przydatny w środowiskach, w których dane pochodzą z kilku systemów, ponieważ pozwala jasno ustalić ich pochodzenie. W analizie umożliwia filtrowanie danych według źródła, a także może służyć do weryfikacji danych i zarządzania nimi. Dlaczego to ważne Informuje o pochodzeniu danych, co ma znaczenie dla zarządzania nimi i integracji danych z wielu systemów. Skąd pobrać Zwykle jest to stała wartość („Ramp”) dodawana podczas wyodrębniania i przekształcania danych. Przykłady Ramp
	Wynik audytu AuditOutcome	Wynik wewnętrznego lub zewnętrznego audytu raportu wydatków.
Opis W przypadku raportów wydatków objętych formalnym audytem ten atrybut zapisuje jego końcowy wynik, na przykład „Zatwierdzono”, „Odrzucono częściowo” lub „Wymagane dodatkowe informacje”. Dane te są podstawą dashboardu „Skuteczność audytu wydatków”. Pomagają ocenić skuteczność audytu, śledzić częstotliwość poszczególnych wyników i określić finansowe skutki ustaleń audytowych. Dlaczego to ważne Pozwala ocenić skuteczność i wyniki audytu oraz wykryć problemy dotyczące zgodności i kontroli. Skąd pobrać Informacja ta byłaby zapisana w module audytu Ramp lub w zintegrowanym systemie, jeśli jest używany do szczegółowej kontroli wydatków. Przykłady ZaliczonyZaliczony z uwagamiOdrzuconyPrzekazany do dalszej weryfikacji

Wymagane Zalecane Opcjonalne

Czynności w procesie zarządzania wydatkami

To najważniejsze etapy i punkty kontrolne, które należy zapisać w dzienniku zdarzeń, aby prawidłowo odkryć przebieg procesu i mierzyć jego wyniki.

5 Zalecane 7 Opcjonalne

	Działanie	Opis
	Akceptacja przez menedżera	Menedżer sprawdził i zaakceptował wydatek, który może przejść do kolejnego etapu, na przykład weryfikacji finansowej lub zwrotu. Zdarzenie jest rejestrowane po jawnym działaniu użytkownika.
Dlaczego to ważne To ważny etap potwierdzający zakończenie pierwszego poziomu akceptacji. Ma znaczenie przy analizie workflow akceptacji i wykrywaniu wąskich gardeł. Skąd pobrać Zdarzenie jest zapisywane w historii akceptacji wydatku po kliknięciu przez menedżera przycisku „Akceptuj”. Dziennik zdarzeń powinien zawierać identyfikator osoby akceptującej i znacznik czasu. Rejestrowanie Zdarzenie jest rejestrowane po kliknięciu „Akceptuj” przez użytkownika z uprawnieniami menedżera. Typ zdarzenia explicit
	Poniesienie wydatku	Oznacza utworzenie wydatku. Zwykle następuje automatycznie po użyciu karty firmowej albo ręcznie, gdy pracownik dodaje wydatek poniesiony z własnych środków. Zdarzenie jest zazwyczaj rejestrowane na podstawie danych o transakcji lub działań w interfejsie użytkownika.
Dlaczego to ważne To główne zdarzenie rozpoczynające cykl obsługi wydatku. Analiza czasu od tego momentu pomaga zrozumieć opóźnienia w zgłoszeniach i ogólne tempo procesu. Skąd pobrać Zdarzenie można ustalić na podstawie dzienników transakcji kartowych Ramp lub znacznika czasu utworzenia wydatku wprowadzonego ręcznie. Należy znaleźć zdarzenie utworzenia pierwszego wpisu w tabeli wydatków lub transakcji. Rejestrowanie Zdarzenie jest rejestrowane bezpośrednio podczas przetwarzania transakcji kartowej lub dodawania nowego wydatku przez użytkownika. Typ zdarzenia explicit
	Realizacja zwrotu wydatku	Zwrot wydatku został pomyślnie przetworzony i wypłacony pracownikowi. Zwykle jest to ostatni etap z perspektywy pracownika i koniec cyklu płatności.
Dlaczego to ważne To główne zdarzenie kończące proces zwrotu wydatku. Czas od zgłoszenia do tego momentu jest ważnym KPI związanym z zadowoleniem pracowników i sprawnością procesu. Skąd pobrać Zdarzenie można ustalić na podstawie dzienników przetwarzania płatności lub integracji z dostawcą płatności. Status wydatku w Ramp powinien zmienić się na „Zwrócono” lub „Opłacono”. Rejestrowanie Zdarzenie jest rejestrowane, gdy system płatności potwierdzi pomyślne przekazanie środków. Typ zdarzenia explicit
	Synchronizacja z systemem księgowym	Dane transakcji dotyczącej wydatku zostały pomyślnie zaksięgowane w zintegrowanym systemie księgowym, takim jak NetSuite, QuickBooks lub Xero. To zdarzenie oznacza zakończenie etapu ewidencji finansowej.
Dlaczego to ważne To ostatnie działanie w całym procesie. Opóźnienia na tym etapie mogą obniżyć dokładność raportowania finansowego i wydłużyć zamknięcie okresu finansowego. Skąd pobrać Zdarzenie jest zapisywane w dzienniku integracji lub jako zmiana statusu wydatku w Ramp. Należy szukać statusu takiego jak „Zsynchronizowano”, „Zaksięgowano” lub „Wyeksportowano”. Rejestrowanie Po pomyślnej synchronizacji danych usługa integracji z systemem księgowym tworzy wpis w dzienniku. Typ zdarzenia explicit
	Zgłoszenie wydatku	Pracownik potwierdza, że wszystkie wymagane informacje o wydatku są kompletne, i przekazuje go do akceptacji. To jawne działanie użytkownika, które zmienia status wydatku z „roboczy” lub „wymaga uwagi” na „oczekuje na akceptację”.
Dlaczego to ważne To ważny etap, który formalnie rozpoczyna cykl akceptacji i zwrotu wydatków. Stanowi punkt odniesienia przy pomiarze SLA akceptacji i zwrotu. Skąd pobrać Zdarzenie można ustalić na podstawie historii statusów wydatku. Odpowiada ono działaniu użytkownika polegającemu na przekazaniu transakcji do weryfikacji. Rejestrowanie Zdarzenie jest rejestrowane po kliknięciu przez użytkownika przycisku „Prześlij”, co powoduje zmianę statusu. Typ zdarzenia explicit
	Akceptacja przez dział finansowy	Zespół finansowy sprawdził wydatek i udzielił ostatecznej akceptacji, umożliwiając zwrot środków i synchronizację z systemem księgowym. Zdarzenie jest rejestrowane po jawnym działaniu członka zespołu finansowego.
Dlaczego to ważne To ostatni etap akceptacji przed płatnością. Analiza tego działania pomaga zrozumieć cały cykl akceptacji i ocenić sprawność zespołu finansowego. Skąd pobrać Zdarzenie jest zapisywane w historii akceptacji wydatku. Należy szukać zdarzenia akceptacji powiązanego z użytkownikiem z działu finansowego. Rejestrowanie Zdarzenie jest rejestrowane po kliknięciu „Akceptuj” przez użytkownika z uprawnieniami działu finansowego. Typ zdarzenia explicit
	Dołączenie paragonu	Oznacza moment powiązania paragonu z wydatkiem, automatycznie przez dopasowanie OCR lub ręcznie przez użytkownika. Zdarzenie jest rejestrowane po pomyślnym połączeniu pliku paragonu z rekordem transakcji.
Dlaczego to ważne Śledzenie tego działania pomaga wykrywać opóźnienia spowodowane brakiem dokumentów. To ważny etap zapewniający zgodność z zasadami i gotowość do audytu. Skąd pobrać Zdarzenie jest rejestrowane w historii wydatku lub transakcji po przesłaniu albo dopasowaniu paragonu. Należy sprawdzić, czy występuje zdarzenie utworzenia załącznika lub flaga „receipt_attached”. Rejestrowanie Zdarzenie powstaje, gdy system łączy obraz lub plik paragonu z rekordem wydatku. Typ zdarzenia explicit
	Kontrola zgodności z zasadami	System automatycznie sprawdza wydatek pod kątem skonfigurowanych zasad firmowych i oznacza potencjalne naruszenia. Zwykle jest to zdarzenie generowane przez system krótko po zgłoszeniu wydatku.
Dlaczego to ważne Pozwala ocenić sprawność automatycznych kontroli zgodności i ich wpływ na proces. Pomaga wykrywać częste naruszenia zasad oraz wskazywać obszary, w których pracownicy potrzebują szkolenia. Skąd pobrać Zdarzenie prawdopodobnie znajduje się w ścieżce audytu lub dzienniku powiązanym z transakcją. Należy szukać zdarzeń systemowych związanych z „policy_check” lub „compliance_scan”. Rejestrowanie Po sprawdzeniu transakcji przez automatyczny mechanizm kontroli zasad w dzienniku systemowym pojawia się wpis. Typ zdarzenia explicit
	Oczekiwanie na weryfikację finansową	Zaakceptowany wydatek został przekazany do dalszej weryfikacji przez zespół finansowy lub księgowy. Zwykle dotyczy to wydatków o wysokiej wartości lub oznaczonych jako potencjalnie niezgodne z zasadami. Zdarzenie można ustalić na podstawie zmiany statusu.
Dlaczego to ważne Oznacza początek weryfikacji finansowej. Pomiar czasu tego etapu pomaga ocenić obciążenie i sprawność zespołu finansowego oraz wskazać możliwości automatyzacji. Skąd pobrać Zdarzenie można ustalić na podstawie zmiany statusu wydatku na „Oczekuje na akceptację działu finansowego” po akceptacji menedżera. Wymaga to dostępu do historii statusów wydatku. Rejestrowanie Ustalany na podstawie znacznika czasu, w którym status wydatku zmienia się na „Oczekuje na weryfikację finansową”. Typ zdarzenia inferred
	Oczekiwanie na weryfikację przez menedżera	Wydatek został zgłoszony i oczekuje na weryfikację przez bezpośredniego menedżera pracownika. Ten stan można rozpoznać po zmianie statusu wydatku na „Oczekuje na akceptację menedżera” lub podobną wartość.
Dlaczego to ważne Oznacza początek etapu akceptacji przez menedżera. Analiza czasu spędzonego w tym stanie pomaga mierzyć i skracać czas akceptacji. Skąd pobrać Stan można ustalić na podstawie zmiany statusu wydatku na „Oczekuje na akceptację” lub podobny oraz przypisania go do kolejki menedżera. Wymaga to śledzenia historii statusów. Rejestrowanie Ustalany na podstawie znacznika czasu, w którym status wydatku zmienia się na „Oczekuje na akceptację menedżera”. Typ zdarzenia inferred
	Odesłanie wydatku do poprawy	Osoba akceptująca, menedżer lub pracownik działu finansowego, odrzuciła wydatek i odesłała go pracownikowi do poprawy. Zdarzenie jest rejestrowane jako zmiana statusu na „Wymaga poprawy” lub „Odrzucony”.
Dlaczego to ważne To działanie oznacza konieczność ponownego wykonania części procesu, co bezpośrednio wydłuża jego czas. Śledzenie takich zdarzeń pomaga wykrywać częste błędy w zgłoszeniach i zwiększać odsetek zgłoszeń poprawnych za pierwszym razem. Skąd pobrać Zdarzenie można ustalić na podstawie zmiany statusu wydatku na „Wymaga poprawy” lub podobny. Powinno być powiązane z osobą akceptującą, która zainicjowała działanie. Rejestrowanie Ustalany na podstawie znacznika czasu, w którym status wydatku zmienia się na „Wymaga poprawy” lub „Odrzucony”. Typ zdarzenia inferred
	Zaplanowanie zwrotu wydatku	W przypadku wydatków poniesionych z własnych środków zaakceptowana kwota trafia do kolejki płatności. To zdarzenie oznacza, że wydatek przeszedł wszystkie etapy akceptacji i jest gotowy do wypłaty.
Dlaczego to ważne Ten etap oddziela proces akceptacji od realizacji płatności. Pomaga rozróżnić opóźnienia w płatnościach od opóźnień na etapie akceptacji. Skąd pobrać Zdarzenie można prawdopodobnie ustalić na podstawie zmiany statusu wydatku na „Oczekuje na zwrot” lub „Gotowy do płatności” po ostatecznej akceptacji. Może być też rejestrowane bezpośrednio, jeśli płatności są grupowane. Rejestrowanie Ustalany na podstawie zmiany statusu na „Gotowy do wypłaty” lub utworzenia rekordu w tabeli partii płatności. Typ zdarzenia inferred

Zalecane Opcjonalne

Instrukcje eksportu danych

Jak pobrać dane z Ramp

Kroki

Zaloguj się na konto Ramp z uprawnieniami administratora lub księgowego.
W menu po lewej stronie przejdź do sekcji Transactions. Znajdują się tam wszystkie wydatki opłacone kartą firmową.
Ustaw odpowiednie filtry danych. Co najmniej wybierz Date Range, czyli okres, który ma zostać przeanalizowany. W razie potrzeby można też zawęzić zakres za pomocą innych filtrów, takich jak Status, Category lub Department.
Kliknij przycisk Export w prawym górnym rogu listy transakcji.
W oknie eksportu wybierz Transactions jako typ eksportu i CSV jako format. Pobierz plik i nazwij go transactions_export.csv.
Następnie w menu po lewej stronie przejdź do sekcji Reimbursements. Znajdują się tam wszystkie wydatki poniesione przez pracowników z własnych środków.
Ustaw ten sam zakres dat co przy eksporcie transakcji, aby zachować spójność danych.
Kliknij przycisk Export i pobierz dane dotyczące zwrotów kosztów w formacie CSV. Nazwij plik reimbursements_export.csv.
Umieść oba wyeksportowane pliki CSV (transactions_export.csv i reimbursements_export.csv) w tym samym katalogu co dostarczony skrypt Python.
Uruchom skrypt Python. Wczyta oba pliki, przekształci dane, tworząc osobny wiersz dla każdego zdarzenia biznesowego, a następnie połączy je w jeden uporządkowany dziennik zdarzeń.
Skrypt utworzy plik ramp_event_log.csv w formacie zgodnym z wymaganiami ProcessMind.
Prześlij plik ramp_event_log.csv do ProcessMind, aby przeprowadzić analizę.

Konfiguracja

Uprawnienia: Aby uzyskać dostęp do pełnych zbiorów danych o transakcjach i zwrotach kosztów oraz je eksportować, trzeba mieć w Ramp rolę „Admin” lub „Bookkeeper”.
Zakres dat: Przy pierwszej analizie wybierz okres obejmujący co najmniej 6–12 miesięcy, aby uwzględnić wystarczającą liczbę wariantów procesu. Do bieżącego monitorowania można użyć krótszego, niedawnego okresu.
Spójność danych: Podczas eksportowania plików Transactions i Reimbursements użyj dokładnie tego samego zakresu dat i filtrów, aby zachować spójność zbioru danych.
Format eksportu: W obu przypadkach wybierz format CSV. Skrypt przekształcający dane obsługuje pliki rozdzielane przecinkami.
Nazwy plików: Użyj nazw transactions_export.csv i reimbursements_export.csv albo odpowiednio zmień ścieżki do plików w skrypcie przekształcającym dane.

Przykładowe zapytanie python

import pandas as pd
import numpy as np

class=class="hl-string">"hl-comment"># --- Configuration ---
TRANSACTIONS_FILE = class="hl-string">'transactions_export.csv'
REIMBURSEMENTS_FILE = class="hl-string">'reimbursements_export.csv'
OUTPUT_FILE = class="hl-string">'ramp_event_log.csv'

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

class=class="hl-string">"hl-comment"># --- Main Transformation Logic ---
def transform_to_event_log(transactions_df, reimbursements_df):
    events = []

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

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

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

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

        class=class="hl-string">"hl-comment"># Activity: Expense Incurred
        if pd.notna(row.get(class="hl-string">'ExpenseIncurredTimestamp')):
            events.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Expense Incurred', class="hl-string">'EventTimestamp': row.get(class="hl-string">'ExpenseIncurredTimestamp')})

        class=class="hl-string">"hl-comment"># Activity: Receipt Attached
        if pd.notna(row.get(class="hl-string">'ReceiptAttachedTimestamp')):
            events.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Receipt Attached', class="hl-string">'EventTimestamp': row.get(class="hl-string">'ReceiptAttachedTimestamp')})

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

        class=class="hl-string">"hl-comment"># Activity: Manager Approved
        if pd.notna(row.get(class="hl-string">'ManagerApprovedTimestamp')):
            events.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Manager Approved', class="hl-string">'EventTimestamp': row.get(class="hl-string">'ManagerApprovedTimestamp')})

        class=class="hl-string">"hl-comment"># Activity: Finance Review Pending
        if pd.notna(row.get(class="hl-string">'FinanceReviewPendingTimestamp')):
            events.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Finance Review Pending', class="hl-string">'EventTimestamp': row.get(class="hl-string">'FinanceReviewPendingTimestamp')})

        class=class="hl-string">"hl-comment"># Activity: Finance Approved
        if pd.notna(row.get(class="hl-string">'FinanceApprovedTimestamp')):
            events.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Finance Approved', class="hl-string">'EventTimestamp': row.get(class="hl-string">'FinanceApprovedTimestamp')})

        class=class="hl-string">"hl-comment"># Activity: Synced with Accounting System
        if pd.notna(row.get(class="hl-string">'SyncedTimestamp')):
            events.append({**base_event, class="hl-string">'ActivityName': class="hl-string">'Synced with Accounting System', class="hl-string">'EventTimestamp': row.get(class="hl-string">'SyncedTimestamp')})

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

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

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

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

    if not events:
        print(class="hl-string">"Warning: No events were generated. Check the input files and column names.")
        return None

    class=class="hl-string">"hl-comment"># Create final DataFrame
    event_log_df = pd.DataFrame(events)
    event_log_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(event_log_df[class="hl-string">'EventTimestamp'])
    event_log_df.sort_values(by=[class="hl-string">'ExpenseReportId', class="hl-string">'EventTimestamp'], inplace=True)
    
    return event_log_df

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

Kroki

Wymagania wstępne i konfiguracja środowiska: Upewnij się, że zainstalowano Python w wersji 3.8 lub nowszej. Zainstaluj wymagane biblioteki Python, uruchamiając polecenie pip install requests pandas. Do wygenerowania danych uwierzytelniających API potrzebny jest również dostęp administratora do instancji Ramp.
Wygeneruj dane uwierzytelniające Ramp API: Zaloguj się na konto Ramp. Przejdź do Settings, a następnie z menu bocznego wybierz Developer API. Kliknij „Create App”, nadaj aplikacji nazwę i skonfiguruj wymagane zakresy uprawnień. Potrzebne będą transactions:read, reimbursements:read i users:read. Po utworzeniu aplikacji bezpiecznie skopiuj Client ID i Client Secret.
Skonfiguruj skrypt Python: Utwórz nowy plik Python, na przykład extract_ramp_log.py. Wklej do niego dostarczony skrypt. Ustaw Client ID i Client Secret jako zmienne środowiskowe albo wpisz je bezpośrednio w skrypcie na potrzeby testów. Ze względów bezpieczeństwa zalecane jest użycie zmiennych środowiskowych.
Ustaw zakres dat eksportu: W bloku wykonawczym main znajdź w skrypcie zmienne START_DATE i END_DATE. Zmień ich wartości, aby określić okres eksportu danych. Przy pierwszej analizie zaleca się wybrać okres od 3 do 6 miesięcy.
Uruchom skrypt: Uruchom skrypt w terminalu poleceniem python extract_ramp_log.py. Skrypt uwierzytelni się w Ramp API, pobierze dane z punktów końcowych users, transactions i reimbursements oraz automatycznie obsłuży stronicowanie wyników.
Poznaj działanie wywołań API: Najpierw skrypt pobiera dane wszystkich użytkowników, aby utworzyć mapowanie identyfikatorów użytkowników na nazwiska i działy. Następnie pobiera wszystkie zwroty kosztów z wybranego okresu. Dla każdego zwrotu odczytuje historię zatwierdzania i płatności.
Przekształć dane w dziennik zdarzeń: Główna część skryptu przechodzi przez każdy zwrot kosztów i powiązaną z nim historię statusów. Każdą zmianę statusu, na przykład „MANAGER_APPROVAL” lub „FINISHED”, zamienia na osobną czynność, taką jak „Oczekiwanie na weryfikację menedżera” lub „Zrealizowano zwrot kosztów”. Skrypt pobiera też powiązane dane transakcji, aby utworzyć zdarzenia „Poniesiono wydatek” i „Dołączono paragon”.
Uzupełnij dane: Skrypt wzbogaca dziennik zdarzeń o dane użytkownika, informacje o dziale i kategorię wydatku dla każdego zdarzenia, tworząc zbiór danych do analizy procesu.
Sprawdź wynik: Po zakończeniu działania skrypt utworzy w tym samym katalogu plik ramp_event_log.csv. Otwórz go w arkuszu kalkulacyjnym, sprawdź dane i upewnij się, że zostały pobrane zgodnie z oczekiwaniami.
Przygotuj plik do przesłania: Wygenerowany plik CSV zawiera wymagane kolumny: ExpenseReportId, ActivityName, EventTimestamp oraz inne zalecane atrybuty. Można go bezpośrednio przesłać na platformę ProcessMind.

Konfiguracja

Dane uwierzytelniające API: Do uwierzytelnienia wymagane są prawidłowe wartości Client ID i Client Secret. Można je wygenerować w dashboardzie Ramp, w sekcji Settings > Developer API.
Zakresy API: Skrypt wymaga określonych uprawnień dostępu do danych. Upewnij się, że dla klucza API włączono następujące zakresy: transactions:read (dane o wydatkach i paragonach), reimbursements:read (przesłanie, zatwierdzanie i status płatności) oraz users:read (nazwiska pracowników i nazwy działów).
Zakres dat: Eksport obejmuje okres określony parametrami START_DATE i END_DATE w skrypcie. Na początek zaleca się wybrać niedawny okres, na przykład ostatnie 3–6 miesięcy, aby ograniczyć rozmiar zbioru danych. Filtr jest stosowany do daty utworzenia zwrotu kosztów.
Stronicowanie: Skrypt automatycznie obsługuje stronicowanie API za pomocą kursora starting_after udostępnianego przez Ramp API. Pobiera rekordy partiami, maksymalnie po 100 na żądanie, aby uwzględnić wszystkie dane z wybranego okresu.
Limity liczby żądań: Ramp API ma limity liczby żądań, zwykle 600 na minutę. Dostarczony skrypt działa wydajnie, ale przy bardzo dużych zbiorach danych może być konieczne wprowadzenie krótkich przerw między wywołaniami API, jeśli pojawią się błędy związane z limitem.

Przykładowe zapytanie 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()

Kroki

Sprawdź, czy subskrypcja Ramp obejmuje natywną integrację z hurtownią danych i czy administrator może skonfigurować miejsce docelowe. Wybierz obsługiwaną hurtownię, na przykład Snowflake lub BigQuery, i skonfiguruj dostęp zgodnie ze standardami bezpieczeństwa organizacji. Dokładne ścieżki w menu i obiekty docelowe zależą od konfiguracji Ramp, dlatego skorzystaj z instrukcji [Skonfiguruj zgodnie z używanym systemem].
Skonfiguruj docelową hurtownię, bazę danych lub projekt, schemat lub zbiór danych, region, dane uwierzytelniające i zakres synchronizacji. Zapisz nazwy replikowanych tabel i kolumn wyświetlane przez Ramp. Nie zakładaj z góry nazw tabel, ponieważ różnią się one w zależności od integracji i konfiguracji konta.
Zidentyfikuj replikowane dane dotyczące raportów wydatków, transakcji, paragonów, zatwierdzeń, polityk, zwrotów kosztów i synchronizacji księgowej. Przyporządkuj każde źródło do pól wymaganych w dzienniku zdarzeń. Jeśli wymagane zdarzenie z cyklu życia nie jest jawnie reprezentowane, znajdź historię statusów lub dane audytowe, w których jest zapisane.
Określ okres eksportu, najlepiej od trzech do sześciu miesięcy, używając pól [Data początkowa] i [Data końcowa]. Filtry dotyczące firmy lub organizacji stosuj tylko wtedy, gdy odpowiednie pole jest dostępne w źródle. Zachowaj źródłową strefę czasową albo przelicz wszystkie znaczniki czasu na jedną udokumentowaną strefę.
Utwórz widok lub zapytanie w hurtowni, które ujednolici pola źródłowe do postaci ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag i RevisionReason. Zastąp wszystkie ujęte w nawiasy kwadratowe symbole zastępcze nazw tabel i kolumn z dostarczonego zapytania nazwami z replikowanego schematu.
Wyodrębnij każdą czynność z cyklu życia jako osobny wiersz zdarzenia. Poniższe zapytanie zawiera osobny, kompletny blok SELECT dla każdej z 12 wymaganych czynności. Nie wyprowadza zdarzeń z niepowiązanych rekordów. W przypadku czynności opartych na statusie użyj historii statusów lub tabeli zdarzeń, a nie tylko bieżącego statusu raportu, aby zachować wcześniejsze zmiany.
Sprawdź identyfikatory, znaczniki czasu, etykiety czynności, sposób obsługi duplikatów i wartości null. Upewnij się, że każde zdarzenie jest przypisane do właściwego ExpenseReportId, a powtarzające się zdarzenia są zachowane, jeśli źródło zawiera kilka prawidłowych wystąpień.
Wyeksportuj wynik jako CSV lub inny tabelaryczny format obsługiwany przez ProcessMind. Uwzględnij wymagane kolumny o dokładnych nazwach ExpenseReportId, ActivityName i EventTimestamp, a także zalecane atrybuty, jeśli są dostępne. Prześlij plik, używając Expense Report ID jako identyfikatora case. ProcessMind odczytuje dziennik zdarzeń bez zmian, dlatego nie należy oczekiwać, że brakujące czynności zostaną wyznaczone automatycznie.

Konfiguracja

Miejsce docelowe integracji: Skonfiguruj natywną integrację Ramp z hurtownią Snowflake lub BigQuery. Dokładną konfigurację dla danego konta znajdziesz w instrukcji [Skonfiguruj zgodnie z używanym systemem].
Obiekty źródłowe: Użyj replikowanych obiektów dotyczących raportów wydatków, transakcji, paragonów, zatwierdzeń, polityk, zwrotów kosztów i synchronizacji księgowej, udostępnionych w hurtowni. Zastąp symbole zastępcze [Nazwa tabeli] i [Nazwa kolumny] potwierdzonymi nazwami z integracji.
Zakres dat: Zacznij od danych z okresu od trzech do sześciu miesięcy. Wydłuż okres dopiero po sprawdzeniu kosztu korzystania z hurtowni, czasu wykonywania zapytań, liczby zdarzeń i limitów przesyłania ProcessMind.
Filtrowanie dat: Jeśli celem jest uwzględnienie wszystkich czynności z danego okresu, filtruj według znacznika czasu zdarzenia, a nie tylko daty utworzenia raportu.
Filtry organizacyjne: Filtry Company Code, jednostki, działu, programu kartowego i inne stosuj tylko wtedy, gdy odpowiednie pola istnieją w replikowanych danych. Jeśli wymagane jest ograniczenie do konkretnej firmy, użyj [Filtr firmy].
Historia czynności: W miarę możliwości korzystaj z niezmiennych danych audytowych lub historii statusów. Same tabele bieżącego stanu mogą nie zawierać historii dołączania paragonów, przesyłania, zatwierdzania, poprawek, zwrotów kosztów ani synchronizacji księgowej.
Obsługa znaczników czasu: Ujednolić znaczniki czasu do jednej strefy czasowej i udokumentuj, czy wartości źródłowe są podane w UTC, czy w czasie lokalnym. Zachowaj dostępną precyzję danych źródłowych.
Wymagany dostęp: Administrator może potrzebować uprawnień do konfiguracji integracji, tworzenia obiektów w hurtowni lub wykonywania na nich zapytań, a także dostępu do danych o wydatkach, zatwierdzeniach, zwrotach kosztów i księgowości.
Licencje i dostępność: Dostępność replikacji danych do hurtowni, historycznych danych audytowych, danych o zwrotach kosztów i danych synchronizacji księgowej zależy od planu Ramp, włączonych modułów, konfiguracji integracji i zasad przechowywania danych.
Wydajność: Na początku ogranicz zakres dat, wybieraj tylko wymagane kolumny, w razie potrzeby filtruj według organizacji, a przy dużych zbiorach danych utwórz pośredni, ujednolicony widok lub tabelę. Dziel dane na partycje lub klastry zgodnie z funkcjami obsługiwanymi przez daną hurtownię.
Ładowanie przyrostowe: Przy regularnym ładowaniu danych użyj znacznika kontrolnego opartego na największej przetworzonej wartości EventTimestamp i dodaj niewielki nakładający się okres. Usuwaj duplikaty tylko na podstawie potwierdzonego identyfikatora zdarzenia źródłowego, ponieważ usunięcie powtarzających się zdarzeń może zmienić obraz procesu.

Przykładowe zapytanie python

import os
import pandas as pd
from sqlalchemy import create_engine, text

CONNECTION_STRING = os.getenv(class="hl-string">"WAREHOUSE_CONNECTION_STRING", class="hl-string">"[Connection string]")
START_DATE = class="hl-string">"[Start date]"
END_DATE = class="hl-string">"[End date]"
COMPANY_FILTER = class="hl-string">"[Company filter]"

engine = create_engine(CONNECTION_STRING)

sql = text(class="hl-string">"""
WITH
expense_incurred AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Expense Incurred' AS ActivityName,
        [Expense incurred timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your expense incurred table]
    WHERE [Expense incurred timestamp column] >= :start_date
      AND [Expense incurred timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
receipt_attached AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Receipt Attached' AS ActivityName,
        [Receipt attached timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your receipt attachment table]
    WHERE [Receipt attached timestamp column] >= :start_date
      AND [Receipt attached timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
expense_submitted AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Expense Submitted' AS ActivityName,
        [Submission timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your expense submission table]
    WHERE [Submission timestamp column] >= :start_date
      AND [Submission timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
policy_check_performed AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Policy Check Performed' AS ActivityName,
        [Policy check timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your policy check table]
    WHERE [Policy check timestamp column] >= :start_date
      AND [Policy check timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
manager_review_pending AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Manager Review Pending' AS ActivityName,
        [Manager pending timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your expense status history table]
    WHERE [Status column] = 'Pending Manager Approval'
      AND [Manager pending timestamp column] >= :start_date
      AND [Manager pending timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
manager_approved AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Manager Approved' AS ActivityName,
        [Manager approval timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your manager approval table]
    WHERE [Manager approval timestamp column] >= :start_date
      AND [Manager approval timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
finance_review_pending AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Finance Review Pending' AS ActivityName,
        [Finance pending timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your expense status history table]
    WHERE [Status column] = 'Pending Finance Approval'
      AND [Finance pending timestamp column] >= :start_date
      AND [Finance pending timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
finance_approved AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Finance Approved' AS ActivityName,
        [Finance approval timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your finance approval table]
    WHERE [Finance approval timestamp column] >= :start_date
      AND [Finance approval timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
expense_sent_back AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Expense Sent Back for Revision' AS ActivityName,
        [Revision timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        [Revision reason column] AS RevisionReason
    FROM [Your expense status history table]
    WHERE [Status column] IN ('Needs Revision', 'Rejected')
      AND [Revision timestamp column] >= :start_date
      AND [Revision timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
reimbursement_scheduled AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Reimbursement Scheduled' AS ActivityName,
        [Reimbursement scheduled timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your reimbursement schedule table]
    WHERE [Reimbursement scheduled timestamp column] >= :start_date
      AND [Reimbursement scheduled timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
reimbursement_executed AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Reimbursement Executed' AS ActivityName,
        [Reimbursement executed timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your reimbursement payment table]
    WHERE [Reimbursement executed timestamp column] >= :start_date
      AND [Reimbursement executed timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
),
synced_with_accounting AS (
    SELECT
        [Expense report ID column] AS ExpenseReportId,
        'Synced with Accounting System' AS ActivityName,
        [Accounting sync timestamp column] AS EventTimestamp,
        [User name column] AS UserName,
        [Employee department column] AS EmployeeDepartment,
        [Report total amount column] AS ReportTotalAmount,
        [Expense category column] AS ExpenseCategory,
        [Policy violation flag column] AS PolicyViolationFlag,
        CAST(NULL AS VARCHAR(4000)) AS RevisionReason
    FROM [Your accounting synchronization table]
    WHERE [Accounting sync timestamp column] >= :start_date
      AND [Accounting sync timestamp column] < :end_date
      AND ([Company column] = :company_filter OR :company_filter = '[Company filter]')
)
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM expense_incurred
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM receipt_attached
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM expense_submitted
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM policy_check_performed
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM manager_review_pending
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM manager_approved
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM finance_review_pending
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM finance_approved
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM expense_sent_back
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM reimbursement_scheduled
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM reimbursement_executed
UNION ALL
SELECT ExpenseReportId, ActivityName, EventTimestamp, UserName, EmployeeDepartment, ReportTotalAmount, ExpenseCategory, PolicyViolationFlag, RevisionReason FROM synced_with_accounting
ORDER BY ExpenseReportId, EventTimestamp, ActivityName
""")

with engine.connect() as connection:
    event_log = pd.read_sql(
        sql,
        connection,
        params={
            class="hl-string">"start_date": START_DATE,
            class="hl-string">"end_date": END_DATE,
            class="hl-string">"company_filter": COMPANY_FILTER
        }
    )

event_log[class="hl-string">"EventTimestamp"] = pd.to_datetime(event_log[class="hl-string">"EventTimestamp"], errors=class="hl-string">"coerce", utc=True)
event_log = event_log[event_log[class="hl-string">"ExpenseReportId"].notna() & event_log[class="hl-string">"EventTimestamp"].notna()].copy()
event_log.to_csv(class="hl-string">"ramp_expense_event_log.csv", index=False)
print(event_log.head())
print(event_log.groupby(class="hl-string">"ActivityName", dropna=False).size())

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu, aby usprawnić proces zarządzania wydatkami, zwiększyć efektywność i przyspieszyć zatwierdzanie. Zacznij optymalizować operacje już dziś.

Wróć do przewodnika ulepszania procesów

Pobierz szablon

Zwiększ sprawność: usprawnij zarządzanie wydatkami w Ramp

Wskaż nieefektywne działania, usprawnij zatwierdzanie i skróć czas realizacji o 30%.

Rozpocznij okres próbny

Karta kredytowa nie jest wymagana, konfiguracja zajmuje kilka minut.

Szablon danych dotyczących zarządzania wydatkami

Szablon danych dotyczących zarządzania wydatkami

Atrybuty procesu zarządzania wydatkami

Czynności w procesie zarządzania wydatkami

Instrukcje eksportu danych

Eksport transakcji i zwrotów kosztów do CSV w Ramp

Kroki

Konfiguracja

Przykładowe zapytanie python

Eksport danych za pomocą skryptu Python i Ramp Developer API

Kroki

Konfiguracja

Przykładowe zapytanie python

Synchronizacja danych Ramp z hurtownią danych (Snowflake/BigQuery)

Kroki

Konfiguracja

Przykładowe zapytanie python

Gotowi do rozpoczęcia?

Zwiększ sprawność: usprawnij zarządzanie wydatkami w Ramp