Szablon danych dotyczących wydatków
Szablon danych dotyczących wydatków
- Zalecane atrybuty do analizy
- Najważniejsze działania do śledzenia w procesie
- Wskazówki dotyczące pobierania danych
Atrybuty procesu rozliczania wydatków
| Nazwa | Opis | ||
|---|---|---|---|
|
Czas zdarzenia
EventTime
|
Znacznik czasu wskazujący, kiedy wystąpiła dana czynność lub zdarzenie. | ||
|
Opis
Czas zdarzenia określa dokładną datę i godzinę każdej czynności w procesie. Ta informacja pozwala ustalić chronologiczną kolejność zdarzeń, co ma podstawowe znaczenie dla process mining. Znaczniki czasu służą do obliczania czasu między czynnościami, wykrywania oczekiwania i opóźnień oraz analizy wyników procesu w różnych okresach. Na ich podstawie obliczane są między innymi KPI „Średni czas weryfikacji przez menedżera” i „Opóźnienie realizacji zwrotu”. Wspierają też analizę wąskich gardeł i monitorowanie wyników.
Dlaczego to ważne
Znacznik czasu jest niezbędny do obliczania wszystkich miar opartych na czasie, takich jak czas obsługi i czas oczekiwania, które pomagają wykrywać opóźnienia.
Skąd pobrać
Każde zdarzenie lub rekord transakcji w Brex powinien mieć przypisany znacznik czasu. Można go znaleźć w odpowiedziach API lub eksportach danych dotyczących raportów wydatków.
Przykłady
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:00:00Z
|
|||
|
Identyfikator raportu wydatków
ExpenseReportId
|
Unikalny identyfikator raportu wydatków, używany jako główny identyfikator sprawy do śledzenia jej przebiegu. | ||
|
Opis
Identyfikator raportu wydatków stanowi podstawę procesu zarządzania wydatkami. Łączy wszystkie powiązane czynności, od utworzenia i przesłania raportu po jego zatwierdzenie i zwrot wydatków, w jedną sprawę. W process mining ten identyfikator umożliwia analizę całego przebiegu każdego raportu. Pozwala odtworzyć dokładną ścieżkę raportu, zmierzyć całkowity czas obsługi, wykryć cykle poprawek po odesłaniu raportu oraz analizować warianty procesu, aby zrozumieć typowe i nietypowe przebiegi.
Dlaczego to ważne
Ten identyfikator pozwala śledzić cały przebieg raportu wydatków i analizować czas obsługi, wąskie gardła oraz odstępstwa od procesu.
Skąd pobrać
To podstawowy identyfikator w module zarządzania wydatkami Brex. Zwykle jest dostępny we wszystkich eksportach danych i punktach końcowych API dotyczących raportów wydatków.
Przykłady
ER-2023-08-1012ER-2023-09-2345ER-2023-10-5567
|
|||
|
Nazwa czynności
ActivityName
|
Nazwa konkretnego zdarzenia lub zadania, które wystąpiło w trakcie obsługi raportu wydatków. | ||
|
Opis
Nazwa czynności opisuje etap procesu, na przykład „Przesłanie raportu wydatków”, „Zatwierdzenie przez menedżera” lub „Realizacja zwrotu wydatków”. Zdarzenia te tworzą sekwencję działań składających się na przebieg procesu. Analiza tych czynności pozwala przedstawić mapę procesu, wykryć wąskie gardła między etapami i obliczyć częstotliwość różnych wyników, takich jak zatwierdzenia i odrzucenia. Dzięki temu można zrozumieć, jak przebiega zarządzanie wydatkami.
Dlaczego to ważne
Ten atrybut jest niezbędny do utworzenia mapy procesu i zrozumienia kolejności zdarzeń dotyczących każdego raportu wydatków.
Skąd pobrać
Informacje pochodzą z dzienników zdarzeń lub statusów transakcji w systemie Brex. Może być konieczne przypisanie kodów statusu lub typów zdarzeń do czytelnych nazw.
Przykłady
Utworzenie raportu wydatkówZatwierdzenie przez menedżeraOdrzucenie przez dział finansowyRealizacja zwrotu wydatków
|
|||
|
Dział pracownika
EmployeeDepartment
|
Dział, do którego należy pracownik, który przesłał raport wydatków. | ||
|
Opis
Ten atrybut wskazuje dział pracownika, który przesłał raport, na przykład sprzedaż, inżynierię lub marketing. To ważny wymiar organizacyjny analizy. Analiza danych według działów pomaga wykrywać różnice w przebiegu procesu, wąskie gardła i problemy ze zgodnością w poszczególnych częściach organizacji. Może na przykład ujawnić, że w jednym dziale odsetek odrzuceń jest znacznie wyższy lub zatwierdzanie trwa dłużej niż w innych. Może to wskazywać na potrzebę dodatkowego szkolenia lub zmian w procesie. Atrybut przydaje się też do monitorowania budżetów działów i przypisywania kosztów.
Dlaczego to ważne
Umożliwia filtrowanie i porównywanie wyników procesu w różnych jednostkach biznesowych, co pomaga wykrywać problemy i trendy dotyczące konkretnych działów.
Skąd pobrać
Informacje pochodzą zwykle z profilu pracownika w Brex, który często jest synchronizowany z systemem kadrowym.
Przykłady
SprzedażInżynieriaMarketingFinanse
|
|||
|
Flaga naruszenia zasad
PolicyViolationFlag
|
Flaga logiczna wskazująca, czy raport wydatków oznaczono jako naruszający zasady. | ||
|
Opis
Ten atrybut przyjmuje wartość true lub false. Brex ustawia go, gdy automatyczny mechanizm kontroli zasad wykryje możliwe naruszenie, na przykład przekroczenie limitu dla danej kategorii wydatków lub brak paragonu. Flaga jest podstawą analizy zgodności i KPI „Odsetek naruszeń zasad”. Pozwala szybko filtrować niezgodne raporty i sprawdzać ich wpływ na czas obsługi oraz odsetek odrzuceń. Analiza oznaczonych raportów pomaga dopracować firmową politykę i wskazać obszary, w których pracownicy potrzebują dodatkowych wyjaśnień.
Dlaczego to ważne
Bezpośrednio wspiera monitorowanie zgodności i pomaga określić wpływ naruszeń zasad na sprawność procesu oraz konieczność ponownego wykonania pracy.
Skąd pobrać
To prawdopodobnie pole logiczne lub wskaźnik statusu w danych raportu wydatków w Brex, często zarządzany przez mechanizm kontroli zasad.
Przykłady
truefalse
|
|||
|
Łączna kwota
TotalAmount
|
Łączna wartość pieniężna raportu wydatków. | ||
|
Opis
Ten atrybut określa łączną kwotę zgłoszoną w raporcie wydatków. To ważna miara finansowa, która pomaga zrozumieć wzorce wydatków i finansowe skutki procesu. W analizie można podzielić raporty według przedziałów kwot, na przykład na wysokie i niskie. Mogą one podlegać różnym ścieżkom zatwierdzania lub poziomom kontroli. Atrybut jest też potrzebny do raportowania finansowego, analizy budżetu oraz wykrywania trendów wydatków według działu lub kategorii.
Dlaczego to ważne
Ten atrybut umożliwia analizę finansową, na przykład wykrywanie raportów o wysokich kwotach, które mogą wymagać dokładniejszej kontroli lub dłuższego zatwierdzania.
Skąd pobrać
To standardowe pole każdego raportu wydatków w Brex. Jest dostępne w głównym obiekcie raportu w odpowiedziach API lub eksportach danych.
Przykłady
150.752500.0079.99
|
|||
|
Status raportu
ReportStatus
|
Bieżący status raportu wydatków w toku obsługi. | ||
|
Opis
Status raportu informuje, na jakim etapie znajduje się raport wydatków, na przykład „Oczekuje na zatwierdzenie przez menedżera”, „Zatwierdzony”, „Opłacony” lub „Odrzucony”. Ten atrybut jest ważny dla monitorowania operacji, zwłaszcza na dashboardzie „Monitor statusu otwartych raportów wydatków”. Pozwala menedżerom i zespołom finansowym szybko sprawdzić bieżące obciążenie, wykryć raporty zatrzymane na danym etapie i ustalić kolejność działań. Analiza czasu spędzonego w każdym statusie pomaga wskazać opóźnienia i nieefektywne elementy procesu.
Dlaczego to ważne
Pokazuje bieżący etap obsługi raportu wydatków, co jest ważne dla dashboardów operacyjnych i monitorowania statusu.
Skąd pobrać
To ważne pole statusu obiektu raportu wydatków w Brex.
Przykłady
OCZEKUJE_NA_ZATWIERDZENIEZATWIERDZONYODRZUCONYOPŁACONY
|
|||
|
Użytkownik wykonujący zdarzenie
EventUser
|
Użytkownik, który wykonał daną czynność, na przykład menedżer zatwierdzający raport. | ||
|
Opis
Atrybut „Użytkownik wykonujący zdarzenie” wskazuje osobę odpowiedzialną za daną czynność. Może to być pracownik przesyłający raport, menedżer go weryfikujący lub członek zespołu finansowego realizujący zwrot wydatków. Atrybut jest niezbędny do analizy obciążenia pracą i monitorowania wyników, na przykład na dashboardzie „Wyniki i obciążenie osób zatwierdzających”. Pomaga ustalić, kto obsługuje najwięcej raportów, kto zatwierdza je najszybciej i czy konkretna osoba nie staje się wąskim gardłem procesu. Ułatwia to równomierny podział pracy i wskazanie osób, które potrzebują wsparcia.
Dlaczego to ważne
Wskazuje osobę odpowiedzialną za czynność, umożliwiając analizę obciążenia pracą, monitorowanie wyników i wykrywanie wąskich gardeł na poziomie poszczególnych osób.
Skąd pobrać
Dane te są zwykle zapisywane w ścieżce audytowej lub historii zdarzeń raportu wydatków w Brex.
Przykłady
john.smith@example.comjane.doe@example.combot-finansowy
|
|||
|
Czas zakończenia
EndTime
|
Znacznik czasu wskazujący, kiedy zakończono działanie. | ||
|
Opis
StartTime (EventTime) oznacza początek działania, a EndTime jego zakończenie. Ma to największe znaczenie w przypadku działań trwających przez określony czas, takich jak „Rozpoczęto weryfikację przez menedżera” i „Menedżer zatwierdził”. Dostępność czasu rozpoczęcia i zakończenia działania pozwala dokładnie obliczyć czas jego realizacji i oddzielić go od poprzedzającego go czasu oczekiwania. Dzięki temu można precyzyjnie zmierzyć czas potrzebny na wykonanie pracy, co jest ważne przy analizie wąskich gardeł.
Dlaczego to ważne
Umożliwia dokładne obliczenie czasu realizacji działań, niezależnie od czasu oczekiwania, co pozwala trafniej analizować wąskie gardła.
Skąd pobrać
EndTime często odpowiada StartTime kolejnego działania w sekwencji. Może też pochodzić z osobnego pola w danych źródłowych, jeśli dla działania określono czas trwania.
Przykłady
2023-10-26T10:05:12Z2023-10-26T14:40:00Z2023-10-27T09:15:25Z
|
|||
|
Czy wymagało poprawek
IsRework
|
Obliczany wskaźnik przyjmuje wartość „true”, jeśli raport co najmniej raz odesłano do poprawy. | ||
|
Opis
Ten atrybut logiczny jest wyliczany na podstawie przebiegu procesu. Przyjmuje wartość „true” dla każdego raportu wydatków, w którego historii występuje działanie „Odesłano raport do poprawy”. Pozwala łatwo oznaczać i analizować sprawy, w których konieczne było ponowne wykonanie pracy. Wskaźnik służy do obliczania KPI „Odsetek raportów wydatków wymagających poprawek” i zasila dashboard „Analiza naruszeń zasad i poprawek”. Ułatwia porównanie spraw, które przebiegły bez zakłóceń, z tymi, które odesłano do poprawy. Dzięki temu można określić czas i koszt ponownego wykonania pracy.
Dlaczego to ważne
Wskazuje raporty wydatków wymagające dodatkowej pracy i korekt, co pozwala analizować przyczyny i koszty poprawek.
Skąd pobrać
Tego atrybutu nie ma w systemie źródłowym. Jest obliczany przez sprawdzenie, czy sekwencja działań w danej sprawie zawiera „Odesłano raport do poprawy” lub podobne działanie oznaczające konieczność poprawek.
Przykłady
truefalse
|
|||
|
Czy zautomatyzowano
IsAutomated
|
Wskaźnik logiczny informujący, czy działanie wykonał użytkownik systemowy lub bot. | ||
|
Opis
Ten atrybut wskazuje, czy działanie wykonał automatycznie system, na przykład podczas automatycznej kontroli zasad, czy człowiek, na przykład przy ręcznym zatwierdzaniu. Rozróżnienie działań automatycznych i ręcznych pozwala ocenić poziom automatyzacji procesu. Ułatwia sprawdzenie skuteczności systemów opartych na regułach i wskazanie możliwości dalszej automatyzacji. Można na przykład ustalić, ile raportów zatwierdzono automatycznie, a ile wymagało ręcznej interwencji, i na tej podstawie zwiększać udział obsługi bez udziału człowieka.
Dlaczego to ważne
Pomaga mierzyć poziom automatyzacji procesu i wskazuje, które kroki wykonują ludzie, a które system.
Skąd pobrać
Zazwyczaj ustala się to na podstawie użytkownika przypisanego do zdarzenia. Zdarzenia wygenerowane przez system są często powiązane z ogólnym użytkownikiem „system” lub „bot”.
Przykłady
truefalse
|
|||
|
Data ostatniej aktualizacji danych
LastDataUpdate
|
Znacznik czasu ostatniego odświeżenia danych z systemu źródłowego. | ||
|
Opis
Ten atrybut informuje, jak aktualne są analizowane dane. Zapisuje datę i godzinę ostatniego pomyślnego wyodrębnienia danych z Brex. Znajomość czasu ostatniej aktualizacji pozwala ocenić aktualność wniosków. Ułatwia sprawdzenie, czy dashboardy pokazują bieżący stan operacji, czy opierają się na starszych danych, i pomaga właściwie ocenić ich aktualność.
Dlaczego to ważne
Informuje o aktualności danych, co ma znaczenie przy podejmowaniu trafnych decyzji operacyjnych na podstawie bieżących informacji.
Skąd pobrać
Ten znacznik czasu generuje narzędzie lub proces wyodrębniania danych po ich pomyślnym pobraniu z Brex.
Przykłady
2023-11-20T02:00:00Z2023-11-21T02:00:00Z
|
|||
|
Imię i nazwisko pracownika
EmployeeName
|
Imię i nazwisko pracownika, który utworzył i przesłał raport wydatków. | ||
|
Opis
Ten atrybut określa pracownika, w imieniu którego złożono raport wydatków. Atrybut „Użytkownik wykonujący zdarzenie” wskazuje osobę, która wykonała czynność, a „Imię i nazwisko pracownika” określa osobę, której dotyczy raport. Analiza pozwala śledzić wydatki poszczególnych pracowników. Może wskazać osoby, które często przesyłają raporty naruszające zasady lub których raporty są regularnie odrzucane, co może oznaczać potrzebę dodatkowego szkolenia. Pomaga też zrozumieć wzorce wydatków różnych pracowników i osób na różnych stanowiskach.
Dlaczego to ważne
Wskazuje osobę, której dotyczy raport wydatków, i pozwala analizować jakość zgłoszeń oraz zgodność na poziomie poszczególnych pracowników.
Skąd pobrać
To podstawowa informacja w każdym raporcie wydatków, powiązana z profilem użytkownika, który utworzył raport w Brex.
Przykłady
Alicja JohnsonRobert WilliamsMaria Garcia
|
|||
|
Kategoria wydatku
ExpenseCategory
|
Kategoria przypisana do wydatku, na przykład podróże, posiłki lub oprogramowanie. | ||
|
Opis
Kategoria wydatku to klasyfikacja wybierana przez pracownika w celu określenia rodzaju wydatku. Służy do celów księgowych, budżetowania i egzekwowania zasad. W process mining podział wydatków na kategorie pozwala dokładniej analizować proces. Można sprawdzić, czy zatwierdzanie niektórych rodzajów wydatków, na przykład podróży zagranicznych, trwa dłużej lub częściej kończy się odrzuceniem. Taka analiza pomaga dopracować zasady i procesy dotyczące konkretnych rodzajów wydatków.
Dlaczego to ważne
Umożliwia analizę procesu według rodzaju wydatków i pomaga wykryć różnice w przebiegu lub wąskie gardła dla poszczególnych kategorii.
Skąd pobrać
To standardowe pole pozycji wydatku. Jeśli raport obejmuje kilka kategorii, dane trzeba zagregować na poziomie raportu.
Przykłady
Bilety lotniczePosiłki i rozrywkaSubskrypcje oprogramowaniaMateriały biurowe
|
|||
|
Kraj
Country
|
Kraj przypisany do pracownika lub transakcji wydatku. | ||
|
Opis
Ten atrybut wskazuje kraj, w którym znajduje się główne biuro pracownika lub centrum kosztów. W firmach działających na wielu rynkach jest to ważny wymiar analizy porównawczej. Analiza procesu według kraju może ujawnić regionalne różnice w jego sprawności, poziomie zgodności lub sposobie wydatkowania środków. Na przykład zatwierdzanie może trwać dłużej w jednym kraju ze względu na lokalne przepisy lub inną strukturę zarządzania. Te informacje pomagają ujednolicać procesy w skali globalnej, z uwzględnieniem lokalnych potrzeb.
Dlaczego to ważne
Umożliwia analizę sprawności procesu i zgodności w różnych regionach geograficznych, co ma duże znaczenie dla organizacji międzynarodowych.
Skąd pobrać
Dane pochodzą z profilu pracownika w Brex, który często jest synchronizowany z centralnym systemem HR.
Przykłady
USACANGBRDEU
|
|||
|
Metoda płatności
PaymentMethod
|
Informuje, jak opłacono wydatek, na przykład kartą firmową lub ze środków prywatnych. | ||
|
Opis
Ten atrybut rozróżnia wydatki opłacone kartą Brex wydaną przez firmę od wydatków pokrytych z własnych środków pracownika, które wymagają zwrotu. To rozróżnienie jest istotne, ponieważ przebieg procesu może się znacznie różnić w zależności od metody płatności. Transakcje kartą firmową mogą wymagać weryfikacji i uzgodnienia, a zwrot wydatków obejmuje zgłoszenie i wypłatę. Analiza według metody płatności pomaga wyodrębnić problemy charakterystyczne dla każdego przebiegu i usprawniać je niezależnie.
Dlaczego to ważne
Przebieg procesu i wymagane kroki często różnią się w przypadku wydatków opłaconych kartą firmową i zwrotów za wydatki pokryte z własnych środków. Dlatego ten atrybut jest ważny przy analizie wariantów.
Skąd pobrać
Informacja ta wynika bezpośrednio z danych transakcji w Brex.
Przykłady
Karta firmowa BrexZwrot wydatkówPłatności za faktury
|
|||
|
Paragony dołączone na czas
ReceiptsAttachedOnTime
|
Wskaźnik informujący, czy paragony dołączono przed złożeniem raportu. | ||
|
Opis
Ten obliczany atrybut logiczny służy do mierzenia przestrzegania dobrej praktyki procesowej: dołączania wszystkich wymaganych paragonów przed przekazaniem raportu wydatków do weryfikacji. Przyjmuje wartość „true”, jeśli w danej sprawie działanie „Dołączono paragony” występuje przed działaniem „Złożono raport wydatków”. Wskaźnik bezpośrednio zasila dashboard „Terminowość dołączania paragonów i jej wpływ” oraz KPI „Terminowość dołączania paragonów”. Analiza tego atrybutu pozwala określić, jak często paragony są dołączane z opóźnieniem lub ich brakuje, a także powiązać to z opóźnieniami, odrzuceniami i poprawkami.
Dlaczego to ważne
Mierzy zgodność z zasadami dotyczącymi dołączania paragonów i pomaga wskazać częstą przyczynę opóźnień oraz odrzuceń.
Skąd pobrać
Wartość jest obliczana w narzędziu process mining przez porównanie znaczników czasu działań „Dołączono paragony” i „Złożono raport wydatków” w każdej sprawie.
Przykłady
truefalse
|
|||
|
Powód odrzucenia
RejectionReason
|
Powód podany przez menedżera lub użytkownika z działu finansów przy odrzuceniu raportu wydatków. | ||
|
Opis
Ten atrybut zawiera wpisany tekst lub predefiniowany powód odrzucenia raportu wydatków. W odróżnieniu od automatycznego oznaczenia naruszenia zasad odzwierciedla ręczną decyzję osoby zatwierdzającej. Analiza powodów odrzucenia pomaga zrozumieć przyczyny niepowodzeń procesu i konieczności ponownego wykonania pracy. Ułatwia wykrycie częstych błędów przy składaniu raportów, niejasnych zasad oraz nieporozumień wśród pracowników lub menedżerów. Informacje te można wykorzystać do ulepszenia materiałów szkoleniowych i sekcji FAQ, a w efekcie ograniczyć liczbę odrzuceń i poprawek.
Dlaczego to ważne
Wyjaśnia przyczyny ręcznych odrzuceń i dostarcza informacji zwrotnych, które można wykorzystać do ulepszenia szkoleń użytkowników i ograniczenia przyszłych błędów.
Skąd pobrać
Zazwyczaj jest to pole komentarza, które osoba zatwierdzająca może wypełnić, wybierając w interfejsie Brex opcję „Odrzuć”.
Przykłady
Wybrano nieprawidłową kategorię wydatku.Prosimy o dokładniejsze uzasadnienie biznesowe.Ten zakup nie został wcześniej zatwierdzony.
|
|||
|
System źródłowy
SourceSystem
|
System, z którego wyodrębniono dane. | ||
|
Opis
Ten atrybut wskazuje źródło danych o procesie, którym w tym przypadku jest Brex. Ma znaczenie dla zarządzania danymi i możliwości prześledzenia ich pochodzenia, zwłaszcza gdy analiza obejmuje dane z wielu systemów. Podczas analizy pozwala filtrować i dzielić dane według systemu źródłowego, dzięki czemu miary i mapy procesów można prawidłowo interpretować. Jeśli analizowany jest tylko jeden system, atrybut potwierdza pochodzenie danych.
Dlaczego to ważne
Informuje o pochodzeniu danych, ułatwia ich śledzenie i pozwala prawidłowo filtrować je w środowisku obejmującym wiele systemów.
Skąd pobrać
To stała wartość „Brex”, zwykle dodawana podczas wyodrębniania i przekształcania danych.
Przykłady
BrexBrex-API-v2.1
|
|||
|
Szczegóły naruszenia zasad
PolicyViolationDetails
|
Opis tekstowy konkretnej naruszonej zasady. | ||
|
Opis
Wskaźnik naruszenia zasad informuje, że doszło do naruszenia, a ten atrybut wyjaśnia jego przyczynę. Zawiera szczegóły dotyczące złamanej reguły, na przykład „Przekroczono limit 50 USD na posiłek” lub „Wymagany paragon dla wydatków powyżej 25 USD”. Taki poziom szczegółowości jest bardzo przydatny w dashboardzie „Analiza naruszeń zasad i poprawek”. Pozwala ustalić najczęstsze rodzaje naruszeń i przeanalizować ich przyczyny. Na tej podstawie można podjąć ukierunkowane działania, takie jak doprecyzowanie konkretnej zasady, wysłanie przypomnień pracownikom lub zmiana reguł systemowych.
Dlaczego to ważne
Wskazuje przyczyny naruszeń zasad, co pozwala ukierunkować działania na poprawę zasad, szkolenia użytkowników i konfigurację systemu.
Skąd pobrać
Te informacje można znaleźć w Brex w sekcji notatek dotyczących zgodności lub weryfikacji, powiązanej z oznaczonym wydatkiem.
Przykłady
Wydatek przekracza limit dla danej kategorii.Brakuje paragonu.Wykryto zduplikowany wydatek.
|
|||
|
Waluta
Currency
|
Kod waluty łącznej kwoty raportu wydatków. | ||
|
Opis
Atrybut „Waluta” określa jednostkę łącznej kwoty, na przykład USD, EUR lub GBP. Ma to znaczenie dla prawidłowej analizy finansowej, zwłaszcza w organizacjach międzynarodowych, które korzystają z wielu walut. Atrybut pozwala właściwie interpretować dane finansowe, sumować i porównywać kwoty wydatków. Często wymaga to przeliczenia ich na wspólną walutę raportowania. Dzięki temu nie dochodzi do błędnego sumowania kwot wyrażonych w różnych walutach.
Dlaczego to ważne
Zapewnia poprawność analiz finansowych w środowisku wielowalutowym oraz umożliwia prawidłowe sumowanie i raportowanie kwot wydatków.
Skąd pobrać
To pole jest zwykle dostępne w Brex obok pola kwoty w danych raportu wydatków.
Przykłady
USDEURGBP
|
|||
|
Zatwierdzenie za pierwszym razem
FirstPassApproval
|
Wskaźnik informujący, czy raport zatwierdzono bez odrzucenia ani odesłania do poprawy. | ||
|
Opis
Ten obliczany atrybut logiczny wskazuje najsprawniejsze przypadki procesu. Przyjmuje wartość „true” tylko wtedy, gdy raport wydatków przechodzi całą ścieżkę od złożenia do ostatecznego zatwierdzenia bez odrzucenia ani odesłania do poprawy. Na tej podstawie oblicza się KPI „Odsetek zatwierdzeń za pierwszym razem”, który mierzy jakość i sprawność procesu. Wysoki wynik oznacza, że pracownicy składają poprawne raporty zgodne z zasadami, a proces zatwierdzania jest przejrzysty. Analiza cech raportów, które nie uzyskały zatwierdzenia za pierwszym razem, pomaga wskazać źródła problemów i błędów.
Dlaczego to ważne
Mierzy jakość raportów składanych po raz pierwszy i sprawność głównego workflow, wskazując raporty, które przechodzą proces bez zakłóceń.
Skąd pobrać
Ten atrybut jest obliczany na platformie process mining. Dla każdej sprawy analizowana jest sekwencja działań, aby sprawdzić, czy nie wystąpiło odrzucenie ani odesłanie do poprawy.
Przykłady
truefalse
|
|||
Działania w procesie rozliczania wydatków
| Działanie | Opis | ||
|---|---|---|---|
|
Odesłanie raportu do poprawy
|
Osoba zatwierdzająca, menedżer lub pracownik działu finansowego, odsyła raport pracownikowi do poprawy. W odróżnieniu od definitywnego odrzucenia rozpoczyna to cykl poprawek. | ||
|
Dlaczego to ważne
To główny wskaźnik poprawek. Śledzenie częstotliwości tego zdarzenia jest niezbędne do obliczenia KPI „Odsetek raportów wymagających poprawek” i analizy na dashboardzie „Analiza naruszeń zasad i poprawek”.
Skąd pobrać
Zdarzenie można najpewniej wywnioskować ze zmiany statusu na „Wymaga poprawy” lub „Odesłany”. System powinien zapisać znacznik czasu tej zmiany.
Rejestrowanie
Wnioskowane na podstawie zmiany statusu na przykład na „Wymaga poprawy”, której często towarzyszą komentarze.
Typ zdarzenia
inferred
|
|||
|
Przesłanie raportu wydatków
|
Zdarzenie występuje, gdy pracownik formalnie przesyła wypełniony raport wydatków do zatwierdzenia. Ta czynność użytkownika zmienia status raportu z „Wersja robocza” lub „Otwarty” na „Oczekuje na zatwierdzenie”. | ||
|
Dlaczego to ważne
To ważny moment, który rozpoczyna workflow zatwierdzania. Czas od przesłania raportu do jego ostatecznego zatwierdzenia stanowi istotną część całkowitego czasu obsługi.
Skąd pobrać
Zdarzenie jest zwykle jawnie zapisywane w dzienniku audytowym. Można je też wywnioskować ze zmiany statusu na „Przesłany” lub „Oczekuje na zatwierdzenie przez menedżera” wraz z odpowiadającym jej znacznikiem czasu.
Rejestrowanie
Odczytywane z dziennika zdarzeń lub pola „submission_timestamp” w rekordzie raportu wydatków.
Typ zdarzenia
explicit
|
|||
|
Realizacja zwrotu wydatków
|
To moment faktycznej wypłaty środków pracownikowi. Z perspektywy pracownika jest to ostatni etap i pomyślne zakończenie procesu. | ||
|
Dlaczego to ważne
To główne zdarzenie oznaczające pomyślne zakończenie procesu. Jest potrzebne do obliczenia KPI „Średni czas obsługi od początku do końca” i „Opóźnienie realizacji zwrotu”, które bezpośrednio wpływają na zadowolenie pracowników.
Skąd pobrać
Zdarzenie należy odczytać z dzienników transakcji płatniczych lub potwierdzenia z API banku albo operatora płatności. Odpowiada ono faktycznej dacie realizacji płatności.
Rejestrowanie
Odczytywane z dziennika transakcji płatniczych zawierającego znacznik czasu realizacji.
Typ zdarzenia
explicit
|
|||
|
Utworzenie raportu wydatków
|
To zdarzenie oznacza rozpoczęcie raportu wydatków przez pracownika. System rejestruje je, gdy powstaje nowy raport, jako wersja robocza lub z dodanymi pierwszymi pozycjami wydatków. | ||
|
Dlaczego to ważne
To główne zdarzenie rozpoczynające proces. Analiza czasu od tego momentu do przesłania raportu pomaga zrozumieć zachowania pracowników i wykryć opóźnienia w zgłaszaniu wydatków.
Skąd pobrać
Zdarzenie można najpewniej odczytać ze znacznika czasu utworzenia obiektu lub rekordu raportu wydatków w bazie Brex. Powinien to być najwcześniejszy znacznik czasu powiązany z identyfikatorem raportu.
Rejestrowanie
Ustalane na podstawie daty utworzenia nagłówka raportu wydatków.
Typ zdarzenia
explicit
|
|||
|
Zaksięgowanie
|
To ostatni etap, w którym dane o wydatkach są prawidłowo księgowane w księdze głównej firmy lub systemie ERP. Kończy rozliczenie finansowe raportu wydatków. | ||
|
Dlaczego to ważne
Ta czynność potwierdza zakończenie procesu z punktu widzenia księgowości. Opóźnienie między zwrotem a zaksięgowaniem może wskazywać na problemy z integracją systemów lub workflow księgowym.
Skąd pobrać
Zdarzenie jest prawdopodobnie rejestrowane na podstawie potwierdzenia z API lub aktualizacji statusu po pomyślnej synchronizacji z systemem księgowym. Znacznik czasu wskazuje moment zaksięgowania.
Rejestrowanie
Rejestrowane po pomyślnym wywołaniu zwrotnym API lub aktualizacji statusu w zintegrowanym systemie ERP albo oprogramowaniu księgowym.
Typ zdarzenia
explicit
|
|||
|
Zatwierdzenie przez dział finansowy
|
Dział finansowy zakończył weryfikację i ostatecznie zatwierdził raport wydatków. To ostatni etap zatwierdzania przed realizacją zwrotu. | ||
|
Dlaczego to ważne
To ważny moment, który upoważnia do wypłaty. Kończy pomiar całego cyklu zatwierdzania i rozpoczyna pomiar KPI „Opóźnienie realizacji zwrotu”.
Skąd pobrać
Zdarzenie powinno być jawnie zapisane w historii zatwierdzeń lub ścieżce audytowej wraz z identyfikatorem osoby ostatecznie zatwierdzającej i znacznikiem czasu.
Rejestrowanie
Odczytywane z dziennika zdarzeń lub zmiany statusu na „Zatwierdzony przez dział finansowy” albo „Zatwierdzony do wypłaty”.
Typ zdarzenia
explicit
|
|||
|
Zatwierdzenie przez menedżera
|
Menedżer pierwszego szczebla sprawdził raport wydatków i zatwierdził go do dalszej obsługi. Ta decyzja przenosi raport do kolejnego etapu, zwykle weryfikacji przez dział finansowy lub automatycznego zatwierdzenia. | ||
|
Dlaczego to ważne
Ten etap kończy wstępne zatwierdzanie. Jego śledzenie jest niezbędne do pomiaru czasu zatwierdzania, obciążenia menedżerów i KPI „Odsetek zatwierdzeń za pierwszym razem”.
Skąd pobrać
Zdarzenie jest prawdopodobnie jawnie zapisywane w tabeli historii zatwierdzeń lub ścieżce audytowej wraz z identyfikatorem osoby zatwierdzającej i znacznikiem czasu.
Rejestrowanie
Odczytywane z dziennika zdarzeń lub zmiany statusu na „Zatwierdzony przez menedżera” wraz z odpowiadającym jej znacznikiem czasu.
Typ zdarzenia
explicit
|
|||
|
Dołączenie paragonów
|
Oznacza przesłanie lub dołączenie przez użytkownika obrazu paragonu albo dokumentu do pozycji wydatku. Zwykle system rejestruje to jako osobne zdarzenie ze znacznikiem czasu dla każdego załącznika. | ||
|
Dlaczego to ważne
Śledzenie tej czynności jest niezbędne na dashboardzie „Zgodność paragonów i jej wpływ”. Pozwala sprawdzić, czy opóźnienia lub odrzucenia wiążą się z brakiem paragonu albo jego późniejszym przesłaniem.
Skąd pobrać
Informacja jest prawdopodobnie zapisywana w powiązanej tabeli łączącej załączniki z pozycjami wydatków. Każdy rekord załącznika powinien mieć własny znacznik czasu utworzenia.
Rejestrowanie
Rejestrowane po pomyślnym przesłaniu przez użytkownika pliku powiązanego z pozycją wydatku.
Typ zdarzenia
explicit
|
|||
|
Odrzucenie przez dział finansowy
|
Dział finansowy odrzucił raport wydatków, zwykle z powodu naruszenia zasad, niezgodności lub brakującej dokumentacji. To ostateczne odrzucenie, które kończy proces. | ||
|
Dlaczego to ważne
To ważne zdarzenie wyjątkowe. Analiza jego częstotliwości i przyczyn pomaga zrozumieć problemy ze zgodnością i obliczyć ogólny „Odsetek odrzuconych raportów wydatków”.
Skąd pobrać
Podobnie jak inne decyzje dotyczące zatwierdzania, zdarzenie powinno być jawnie zapisane w ścieżce audytowej wraz z identyfikatorem osoby zatwierdzającej, znacznikiem czasu i przyczyną.
Rejestrowanie
Odczytywane z dziennika zdarzeń lub zmiany statusu na „Odrzucony przez dział finansowy”.
Typ zdarzenia
explicit
|
|||
|
Odrzucenie przez menedżera
|
Menedżer pierwszego szczebla sprawdził i odrzucił raport wydatków. Zwykle kończy to proces albo powoduje odesłanie raportu pracownikowi do poprawy. | ||
|
Dlaczego to ważne
To niekorzystny wynik i wyjątek w procesie. Zdarzenie jest niezbędne do obliczenia „Odsetka odrzuconych raportów wydatków” i ustalenia przyczyn niepowodzeń na pierwszym etapie zatwierdzania.
Skąd pobrać
Podobnie jak zatwierdzenie, zdarzenie powinno być jawnie zapisane w tabeli historii zatwierdzeń lub ścieżce audytowej wraz ze znacznikiem czasu i kodem przyczyny.
Rejestrowanie
Odczytywane z dziennika zdarzeń lub zmiany statusu na „Odrzucony przez menedżera” wraz z odpowiadającym jej znacznikiem czasu.
Typ zdarzenia
explicit
|
|||
|
Oznaczenie naruszenia zasad
|
Zdarzenie automatyczne lub ręczne informujące, że co najmniej jedna pozycja wydatku w raporcie narusza firmową politykę. Może zostać zarejestrowane po uruchomieniu reguły systemowej lub ręcznym oznaczeniu problemu przez osobę sprawdzającą. | ||
|
Dlaczego to ważne
Ta czynność ma zasadnicze znaczenie dla dashboardu „Analiza naruszeń zasad i poprawek” oraz KPI „Odsetek naruszeń zasad”. Pomaga wykrywać częste problemy ze zgodnością i wskazywać obszary wymagające doprecyzowania polityki.
Skąd pobrać
Ustalane na podstawie atrybutu „Policy Violation Flag” ustawionego na true. Znacznik czasu odpowiada chwili ostatniej aktualizacji flagi.
Rejestrowanie
Wnioskowane na podstawie zmiany flagi logicznej lub pola statusu wskazującego naruszenie zasad.
Typ zdarzenia
inferred
|
|||
|
Rozpoczęcie weryfikacji przez dział finansowy
|
Oznacza moment, w którym raport wydatków trafia do kolejki działu finansowego lub księgowości w celu ostatecznej weryfikacji. Zwykle można go wywnioskować ze zmiany statusu po zatwierdzeniu przez menedżera. | ||
|
Dlaczego to ważne
To początek ostatniego, często najważniejszego etapu zatwierdzania. Analiza czasu jego trwania pomaga wykryć wąskie gardła w dziale finansowym.
Skąd pobrać
Wnioskowane na podstawie znacznika czasu zmiany statusu raportu na „Oczekuje na zatwierdzenie przez dział finansowy” lub podobny po zatwierdzeniu przez menedżera.
Rejestrowanie
Wnioskowane na podstawie znacznika czasu zmiany statusu na „Oczekuje na weryfikację przez dział finansowy”.
Typ zdarzenia
inferred
|
|||
|
Rozpoczęcie weryfikacji przez menedżera
|
Oznacza moment, w którym raport wydatków trafia do kolejki zatwierdzania menedżera. Zwykle można go wywnioskować ze zmiany statusu raportu na „Oczekuje na zatwierdzenie przez menedżera” bezpośrednio po jego przesłaniu. | ||
|
Dlaczego to ważne
To początek pierwszego etapu zatwierdzania. Czas od tego momentu do zatwierdzenia lub odrzucenia przez menedżera jest potrzebny do obliczenia KPI „Średni czas weryfikacji przez menedżera”.
Skąd pobrać
Wnioskowane na podstawie znacznika czasu zmiany statusu raportu na „Oczekuje na zatwierdzenie przez menedżera” lub podobny. Często pokrywa się z momentem przesłania raportu wydatków.
Rejestrowanie
Wnioskowane na podstawie znacznika czasu zmiany statusu na „Oczekuje na zatwierdzenie przez menedżera”.
Typ zdarzenia
inferred
|
|||
|
Zaplanowanie zwrotu wydatków
|
Po ostatecznym zatwierdzeniu raport wydatków trafia do kolejki wypłat w najbliższej partii zwrotów. Ta czynność oznacza przekazanie sprawy z etapu zatwierdzania do systemu płatności. | ||
|
Dlaczego to ważne
Ten etap może ujawnić opóźnienia między ostatecznym zatwierdzeniem a rozpoczęciem realizacji płatności. Pozwala odróżnić wąskie gardła w zatwierdzaniu od problemów z wydajnością systemu płatności.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany statusu na „Gotowy do wypłaty” lub „Zaplanowany”. Może też być rejestrowane jawnie, jeśli system łączy się z osobnym systemem płatności lub ERP.
Rejestrowanie
Wnioskowane na podstawie zmiany statusu na „Oczekuje na płatność” lub utworzenia rekordu partii płatności.
Typ zdarzenia
inferred
|
|||
Instrukcje pobierania danych
Gotowi do rozpoczęcia?
Skorzystaj z tego szablonu, aby usprawnić zbieranie danych i szybciej poprawić proces rozliczania wydatków. Już dziś zacznij odkrywać zależności i zwiększać efektywność.
Usprawnij proces rozliczania wydatków w Brex
Skróć czas zatwierdzania o 30% i zwiększ zadowolenie pracowników.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.