Szablon danych do procesu od zakupu do płatności: obsługa faktur

Uniwersalny szablon process mining
Szablon danych do procesu od zakupu do płatności: obsługa faktur

Szablon danych do procesu od zakupu do płatności: obsługa faktur

Uniwersalny szablon process mining

To ogólny szablon danych do process mining dla procesu Obsługa faktur w procesie od zakupu do płatności. Aby uzyskać dokładniejsze wskazówki, skorzystaj z szablonów dla konkretnych systemów.

Wybierz konkretny system
  • Zalecane pola danych do rzetelnej analizy
  • Aktywności i etapy procesu do monitorowania
  • Wskazówki dotyczące pobierania danych o procesie
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty procesu od zakupu do płatności: obsługa faktur

Tabela przedstawia zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby kompleksowo analizować proces od zakupu do płatności obejmujący obsługę faktur.
5 Wymagane 7 Zalecane 5 Opcjonalne
Nazwa Opis
Czas zdarzenia
EventTime
Dokładny znacznik czasu wskazujący, kiedy wystąpiła dana czynność lub zdarzenie.
Opis

Czas zdarzenia, nazywany też czasem rozpoczęcia, określa dokładną datę i godzinę wykonania czynności biznesowej. Każda czynność w procesie, od „Otrzymano fakturę” do „Zrealizowano płatność”, ma przypisany znacznik czasu. Te dane chronologiczne są niezbędne do ustalenia kolejności zdarzeń i obliczenia czasu ich trwania.

Atrybut ten służy do chronologicznego sortowania zdarzeń i odtworzenia przebiegu każdego case. Stanowi podstawę wszystkich analiz czasu, w tym obliczania czasu między czynnościami, wykrywania wąskich gardeł powodujących straty czasu i monitorowania wyników względem uzgodnionych poziomów usług. Dokładne znaczniki czasu są niezbędne, aby wyniki analizy process mining były wiarygodne.

Dlaczego to ważne

Określa chronologiczną kolejność zdarzeń i stanowi podstawę obliczeń dotyczących wydajności oraz czasu trwania, takich jak czas cyklu.

Skąd pobrać

Informacja ta zwykle znajduje się w dziennikach zdarzeń lub w polu „Creation Date” albo „Entry Date” przypisanym do każdej transakcji lub zmiany statusu.

Przykłady
2023-10-26T10:00:00Z2024-01-15T14:35:10Z2023-11-01T09:12:05Z
Nazwa czynności
ActivityName
Nazwa konkretnego zdarzenia biznesowego lub zadania, które wystąpiło podczas obsługi faktury.
Opis

Nazwa czynności opisuje pojedynczy krok lub etap obsługi faktury. Przykłady to „Otrzymano fakturę”, „Przekazano fakturę do akceptacji”, „Nałożono blokadę płatności” i „Zrealizowano płatność”. Ten atrybut pokazuje, co działo się z fakturą na kolejnych etapach.

W process mining atrybut ten służy do tworzenia mapy procesu, która przedstawia przebieg workflow. Analiza kolejności, częstotliwości i ścieżek czynności pomaga wykryć typowe przebiegi procesu, odstępstwa, wąskie gardła i pętle poprawek. Odpowiednia jakość i szczegółowość nazw czynności są niezbędne do przeprowadzenia użytecznej analizy, na podstawie której można podjąć działania.

Dlaczego to ważne

Ten atrybut określa kroki procesu. Stanowi podstawę mapy procesu i umożliwia analizę jego przebiegu.

Skąd pobrać

Informacje te często pochodzą z dzienników zmian statusu, tabel zdarzeń lub kodów transakcji w systemie źródłowym.

Przykłady
Wprowadzono fakturęZaakceptowano fakturęNałożono blokadę płatnościZrealizowano płatność
Numer faktury
InvoiceNumber
Unikalny identyfikator faktury dostawcy. Służy jako podstawowy klucz do śledzenia faktury przez cały cykl jej obsługi.
Opis

Numer faktury to unikalny kod alfanumeryczny nadawany jej przez dostawcę. W process mining ten atrybut ma podstawowe znaczenie, ponieważ zazwyczaj pełni funkcję identyfikatora case, który pozwala śledzić drogę każdej faktury od otrzymania do płatności.

Użycie numeru faktury jako identyfikatora case pozwala połączyć wszystkie powiązane czynności, takie jak „Otrzymano fakturę”, „Zaakceptowano fakturę” i „Zrealizowano płatność”, aby odtworzyć cały proces obsługi konkretnej faktury. Umożliwia to szczegółową analizę czasu trwania, przebiegu i odstępstw dla każdego case. Na tej podstawie można przeprowadzić analizę procesu.

Dlaczego to ważne

To podstawowy identyfikator case, który łączy powiązane zdarzenia i pozwala prześledzić cały cykl obsługi pojedynczej faktury.

Skąd pobrać

To podstawowe pole, które zwykle znajduje się w nagłówku tabeli transakcji faktur.

Przykłady
INV-2024-001239876543210US-5839A-24
Ostatnia aktualizacja danych
LastDataUpdate
Znacznik czasu wskazujący, kiedy dane dotyczące tego zdarzenia zostały ostatnio odświeżone z systemu źródłowego.
Opis

Ten atrybut zapisuje datę i godzinę ostatniego pobrania lub odświeżenia danych. Jest to pole metadanych informujące o aktualności analizowanego zbioru danych.

Informacja ta nie służy bezpośrednio do tworzenia mapy procesu, ale pozwala ocenić aktualność analizy. Ułatwia ustalenie, czy analizowane są dane bieżące, czy migawka z określonego momentu. Ma to znaczenie przy podejmowaniu decyzji operacyjnych. Atrybut pomaga też monitorować stan i częstotliwość działania potoku danych.

Dlaczego to ważne

Informuje o aktualności danych i pozwala ocenić, jak bieżąca jest analiza procesu.

Skąd pobrać

Ten znacznik czasu jest zwykle generowany i dodawany do zbioru danych podczas procesu pobierania, przekształcania i ładowania danych (ETL).

Przykłady
2024-05-21T04:00:00Z2024-05-20T04:00:00Z2024-05-19T04:00:00Z
System źródłowy
SourceSystem
System, z którego pobrano dane o zdarzeniu.
Opis

Atrybut systemu źródłowego wskazuje aplikację lub platformę, w której zarejestrowano zdarzenie związane z obsługą faktury. W złożonym środowisku IT faktura może przechodzić przez kilka systemów, na przykład rozwiązanie do skanowania, narzędzie workflow i system ERP.

Znajomość systemu źródłowego ułatwia interpretację danych i rozwiązywanie problemów z ich jakością. Pozwala też analizować procesy przebiegające w kilku systemach oraz wykrywać problemy z integracją i opóźnienia przy przekazywaniu pracy między aplikacjami. Jest to szczególnie przydatne podczas łączenia danych ze starszych i nowszych systemów.

Dlaczego to ważne

Informacja o pochodzeniu danych jest niezbędna do ich weryfikacji i analizy procesów obejmujących wiele systemów IT.

Skąd pobrać

Często jest to stała wartość dodawana podczas pobierania danych albo pole w dziennikach systemowych wskazujące nazwę lub identyfikator aplikacji.

Przykłady
SAP_ECC_PRODOracle_Fusion_FINCoupa_R34
Czas zakończenia
EndTime
Znacznik czasu wskazujący, kiedy zakończyła się czynność lub wystąpiło zdarzenie. W przypadku zdarzeń chwilowych jest często taki sam jak czas rozpoczęcia.
Opis

Atrybut czasu zakończenia zapisuje dokładny moment zakończenia kroku procesu. Jest niezbędny do precyzyjnego obliczania czasu trwania czynności, co stanowi podstawowy pomiar w process mining. Porównanie czasu rozpoczęcia i zakończenia pozwala analitykom ustalić, ile trwa każdy krok, wykryć wąskie gardła i wskazać możliwości poprawy wydajności.

W analizie czas zakończenia służy do obliczania czasu trwania poszczególnych czynności i całych etapów procesu. Na przykład czas akceptacji faktury można obliczyć, odejmując czas rozpoczęcia od czasu zakończenia czynności „Zaakceptowano fakturę”. Dane te pomagają tworzyć dashboardy wydajności, ustalać wartości odniesienia i monitorować wpływ zmian w procesie.

Dlaczego to ważne

Umożliwia precyzyjne obliczanie czasu trwania czynności, co jest niezbędne do wykrywania wąskich gardeł i pomiaru sprawności obsługi.

Skąd pobrać

Informacja ta znajduje się w dziennikach systemowych lub danych transakcyjnych, często w polu „Completion Date”, „Change Date” albo w osobnym polu znacznika czasu zakończenia czynności.

Przykłady
2023-10-26T10:05:12Z2024-01-15T15:00:00Z2023-11-01T09:12:05Z
Kwota faktury
InvoiceAmount
Łączna wartość faktury.
Opis

Kwota faktury to łączna wartość faktury obejmująca wszystkie pozycje, podatki i opłaty. Ten podstawowy atrybut finansowy określa wartość każdej sprawy. Często analizuje się go razem z innymi atrybutami, aby sprawdzić jego wpływ na przebieg procesu.

Atrybut ten ma znaczenie dla analiz finansowych i ustalania priorytetów. Filtrowanie faktur według kwoty pozwala sprawdzić, czy faktury o wysokiej wartości przechodzą inną, bardziej rygorystyczną ścieżkę zatwierdzania albo częściej się opóźniają. Kwota jest też potrzebna w dashboardach pokazujących łączną wartość obsłużonych faktur oraz w KPI dotyczących wykorzystania rabatów, ponieważ potencjalne oszczędności stanowią procent kwoty faktury.

Dlaczego to ważne

Umożliwia analizę wpływu finansowego i ustalanie priorytetów dla faktur o wysokiej wartości, a także pozwala sprawdzić, czy kwota faktury wpływa na czas lub przebieg jej obsługi.

Skąd pobrać

To standardowe pole w nagłówku tabeli transakcji faktur.

Przykłady
5250.751200.0025000.0089.99
Nazwa dostawcy
VendorName
Nazwa dostawcy, który przesłał fakturę.
Opis

Atrybut ten zawiera nazwę podmiotu zewnętrznego, który wystawił fakturę. Pozwala powiązać transakcję finansową z konkretnym dostawcą. Spójne i poprawne dane o dostawcach są niezbędne do rzetelnego raportowania i analizy.

W process mining nazwa dostawcy jest ważnym wymiarem analizy. Analitycy mogą filtrować proces, aby sprawdzić obsługę faktur od dostawców o dużym wolumenie lub sprawiających problemy. Można w ten sposób wykryć dostawców, którzy często przesyłają błędne faktury, powodując opóźnienia i dodatkową pracę. Analiza wspiera też zarządzanie wynikami dostawców i wskazywanie możliwości rozwoju programów preferowanych dostawców.

Dlaczego to ważne

Pozwala analizować wyniki procesu według dostawcy, co ułatwia zarządzanie dostawcami i wykrywanie źródeł problematycznych faktur.

Skąd pobrać

Informacja ta znajduje się zwykle w nagłówku faktury i jest powiązana z tabelą danych podstawowych dostawców za pomocą identyfikatora dostawcy.

Przykłady
Globalne artykuły biuroweInnowacyjne rozwiązania techniczneCity Logistics Inc.
Przyczyna blokady lub odrzucenia
BlockOrRejectionReason
Przyczyna zablokowania płatności za fakturę lub jej odrzucenia podczas zatwierdzania.
Opis

Atrybut ten wskazuje konkretną przyczynę wstrzymania obsługi faktury: odrzucenie jej w workflow zatwierdzania albo zablokowanie płatności po zatwierdzeniu. Przyczyną może być między innymi nieprawidłowa ilość, niezgodność ceny, brak numeru PO lub zduplikowana faktura.

To jeden z najważniejszych atrybutów w analizie przyczyn źródłowych. Analiza częstotliwości poszczególnych przyczyn pozwala wskazać najczęstsze źródła problemów i nieefektywności w procesie obsługi faktur. Na podstawie tych danych można zająć się przyczynami, na przykład usprawnić komunikację z dostawcami, poprawić zgodność z zasadami dotyczącymi PO lub lepiej przeszkolić pracowników.

Dlaczego to ważne

Jest niezbędny w analizie przyczyn źródłowych i pomaga wskazać najczęstsze powody opóźnień, ponownej pracy i nieefektywności.

Skąd pobrać

Informacja ta znajduje się w polach takich jak „Kod przyczyny” lub „Przyczyna wstrzymania” w danych transakcji faktury albo powiązanych dziennikach zatwierdzania.

Przykłady
Niezgodność cenyNieprawidłowa ilośćZduplikowana fakturaBrak potwierdzenia odbioru towaru
Termin płatności
PaymentDueDate
Data, do której należy opłacić fakturę, aby uniknąć opóźnienia.
Opis

Termin płatności to data wyliczana na podstawie daty faktury i uzgodnionych warunków płatności. Wyznacza ostateczny dzień zapłaty dostawcy, pozwalając uniknąć opóźnienia i związanych z nim kar.

Atrybut ten jest podstawą monitorowania terminowości płatności. Służy do obliczania KPI, takich jak wskaźnik płatności dokonanych w terminie, oraz do wykrywania faktur zagrożonych opóźnieniem. Analiza czasu między zatwierdzeniem faktury a terminem płatności pomaga ocenić sprawność planowania i realizacji końcowych etapów płatności.

Dlaczego to ważne

Jest niezbędny do pomiaru terminowości płatności i analizy przyczyn opóźnień.

Skąd pobrać

Data ta znajduje się zwykle w szczegółach transakcji faktury. Może być wprowadzona bezpośrednio albo wyliczona na podstawie daty faktury i warunków płatności.

Przykłady
2024-06-302024-07-152024-08-01
Użytkownik
User
Użytkownik, pracownik lub agent systemowy, który wykonał daną czynność.
Opis

Atrybut „Użytkownik” wskazuje osobę lub system automatyczny odpowiedzialny za wykonanie danego kroku w workflow przetwarzania faktury. Może to być pracownik działu zobowiązań, który wprowadził fakturę, menedżer, który ją zatwierdził, albo bot, który dopasował dane.

Analiza danych według użytkownika pomaga zrozumieć rozkład obciążenia pracą, wyniki poszczególnych osób i potrzeby szkoleniowe. Pozwala filtrować mapę procesu i sprawdzać, jak różne zespoły lub osoby obsługują faktury oraz czym różnią się ich workflow. Dzięki temu można wskazać osoby osiągające najlepsze wyniki, wykryć problemy z kierowaniem faktur lub ustalić, kto potrzebuje dodatkowego wsparcia albo szkolenia z procedur firmowych.

Dlaczego to ważne

Ułatwia analizę rozkładu obciążenia pracą, wyników użytkowników oraz różnic w przebiegu procesu między zespołami i poszczególnymi osobami.

Skąd pobrać

Informacje te są zwykle dostępne w szczegółach transakcji pod nazwami takimi jak „Nazwa użytkownika”, „Wprowadził”, „Zmienił” lub „Zatwierdzający”.

Przykłady
j.doeSYSTEM_RFCAlice.Smithapprover_pool_1
Waluta faktury
InvoiceCurrency
Kod waluty, w której podano kwotę faktury, na przykład USD lub EUR.
Opis

Atrybut ten określa walutę, w której wyrażono kwotę faktury. Jest niezbędny w organizacjach działających na rynkach międzynarodowych i współpracujących z dostawcami z różnych krajów. Kod waluty, zwykle zgodny ze standardem ISO 4217, pozwala prawidłowo interpretować dane finansowe.

W analizie waluta faktury służy do filtrowania danych według regionu lub kraju. Ma też znaczenie w raportowaniu finansowym, ponieważ kwoty trzeba prawidłowo sumować, często po przeliczeniu na wspólną walutę raportową. Analiza różnic w procesie według waluty może ujawnić złożoność związaną z płatnościami międzynarodowymi lub zarządzaniem ryzykiem walutowym.

Dlaczego to ważne

Daje niezbędny kontekst dla kwot faktur, umożliwiając rzetelną analizę finansową i segmentację danych w działalności międzynarodowej.

Skąd pobrać

To standardowe pole w nagłówku tabeli transakcji faktur.

Przykłady
USDEURGBPJPY
Data faktury
InvoiceDate
Data wystawienia faktury przez dostawcę.
Opis

Data faktury to data podana przez dostawcę na dokumencie. Z perspektywy dostawcy rozpoczyna ona oficjalny cykl płatności i często stanowi podstawę do wyliczenia terminu płatności zgodnie z uzgodnionymi warunkami.

Analiza czasu między datą faktury a zdarzeniem „Otrzymano fakturę” lub „Wprowadzono fakturę” pomaga wykryć opóźnienia w przesyłaniu lub rejestrowaniu faktur. To opóźnienie może stanowić istotną, trudną do zauważenia część całkowitego czasu procesu. Skrócenie go może poprawić terminowość płatności i zwiększyć szanse na skorzystanie z rabatów za wcześniejszą zapłatę.

Dlaczego to ważne

Pozwala zmierzyć opóźnienie między wystawieniem faktury przez dostawcę a jej wprowadzeniem do systemu.

Skąd pobrać

To standardowe pole daty w danych nagłówka faktury, często opisane jako „Data dokumentu” lub „Data faktury”.

Przykłady
2024-05-012024-04-152024-06-10
Kod spółki
CompanyCode
Identyfikator podmiotu prawnego lub spółki w organizacji, która obsługuje fakturę.
Opis

Kod spółki oznacza konkretny podmiot prawny lub spółkę zależną w ramach większej organizacji. W wielu systemach finansowych transakcje są rozdzielane według kodu spółki na potrzeby księgowości i raportowania.

Atrybut ten umożliwia porównywanie różnych jednostek biznesowych. Segmentując mapę procesu według kodu spółki, analitycy mogą porównywać wyniki, wskazywać dobre praktyki w jednej jednostce i wykrywać problemy systemowe w innej. Jest to podstawowy atrybut dla organizacji obejmujących więcej niż jeden podmiot prawny, które chcą zrozumieć różnice w przebiegu procesu i zapewnić zgodność w całej firmie.

Dlaczego to ważne

Umożliwia porównywanie i ocenę procesów w różnych podmiotach prawnych lub jednostkach biznesowych organizacji.

Skąd pobrać

To podstawowe pole organizacyjne, które znajduje się zwykle w nagłówku tabel transakcji finansowych.

Przykłady
1000US01DE015100
Numer zamówienia zakupu
PurchaseOrderNumber
Identyfikator zamówienia zakupu (PO), którego dotyczy faktura.
Opis

Numer zamówienia zakupu łączy fakturę z wcześniej zatwierdzonym dokumentem zakupu. To powiązanie ma zasadnicze znaczenie podczas dopasowywania danych. System sprawdza wtedy, czy szczegóły faktury, takie jak ilości i ceny, są zgodne z zamówieniem PO.

Atrybut ten pomaga ocenić sprawność dopasowywania faktur do zamówień. Wysoki odsetek faktur powiązanych z PO, które są przetwarzane bez ręcznej interwencji, świadczy o sprawnym procesie zakupowym. Z kolei analiza faktur bez PO może ujawnić zakupy poza ustalonym procesem lub przypadki nieprzestrzegania zasad zakupowych. Obecność lub brak PO to częsty sposób segmentacji procesu i porównywania jego sprawności.

Dlaczego to ważne

Pozwala rozróżnić faktury powiązane z PO od faktur bez PO. Często są one obsługiwane w różny sposób i osiągają różny poziom sprawności.

Skąd pobrać

Identyfikator ten znajduje się zwykle w szczegółach pozycji lub nagłówka transakcji faktury i łączy ją z dokumentem zakupu.

Przykłady
4500018921PO-2024-7837300000456
Status faktury
InvoiceStatus
Bieżący stan faktury w workflow jej obsługi.
Opis

Status faktury pokazuje, na jakim etapie cyklu życia znajdowała się faktura w chwili pobrania danych. Typowe statusy to „W trakcie”, „Zatwierdzona”, „Opłacona”, „Odrzucona” lub „Zablokowana”. Atrybut ten przedstawia ogólny bieżący stan faktury.

Process mining odtwarza pełny przebieg procesu, natomiast bieżący status przydaje się w dashboardach operacyjnych monitorujących aktualne obciążenie pracą. Ułatwia menedżerom sprawdzenie liczby faktur na poszczególnych etapach, na przykład oczekujących na zatwierdzenie lub zablokowanych. Dzięki temu można wcześniej reagować na sytuację w kolejce faktur i zapobiegać wąskim gardłom oraz opóźnieniom.

Dlaczego to ważne

Pokazuje bieżące obciążenie pracą i ułatwia monitorowanie liczby faktur na różnych etapach, na przykład oczekujących na zatwierdzenie lub zablokowanych.

Skąd pobrać

To zwykle pole statusu w tabeli nagłówka faktury, aktualizowane w miarę przechodzenia faktury przez kolejne etapy.

Przykłady
OpłaconaW trakcieOdrzuconaZatwierdzona do płatności
Warunki płatności
PaymentTerms
Uzgodnione warunki płatności faktury, które określają termin płatności i ewentualne rabaty za wcześniejszą zapłatę.
Opis

Warunki płatności określają zasady zapłaty za fakturę uzgodnione z dostawcą. Zwykle zapisuje się je w standardowym formacie, na przykład „Net 30” (płatność w ciągu 30 dni) lub „2% 10, Net 30” (rabat 2% przy płatności w ciągu 10 dni, w przeciwnym razie pełna kwota jest płatna w ciągu 30 dni).

Atrybut ten ma znaczenie dla strategii finansowej i analizy wyników. Stanowi podstawę do wyliczenia terminu płatności i wykrywania możliwości skorzystania z rabatu za wcześniejszą zapłatę. Analiza procesu według warunków płatności może pokazać, czy niektóre z nich wiążą się z opóźnieniami oraz czy organizacja skutecznie wykorzystuje dostępne rabaty.

Dlaczego to ważne

Ma znaczenie przy analizie terminowości płatności i wykrywaniu możliwości skorzystania z rabatów za wcześniejszą zapłatę.

Skąd pobrać

Informacje te pochodzą zwykle z danych podstawowych dostawcy i są podawane w nagłówku faktury.

Przykłady
Net 30Net 602% 10, Net 30Płatność przy odbiorze
Wymagane Zalecane Opcjonalne

Proces od zakupu do płatności: obsługa faktur

Poniżej przedstawiono najważniejsze etapy i kamienie milowe, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie odkryć przebieg procesu obsługi faktur w procesie od zakupu do płatności.
7 Zalecane 9 Opcjonalne
Działanie Opis
Odrzucono fakturę
Zdarzenie występuje, gdy osoba akceptująca formalnie odrzuci fakturę, zatrzymując jej dalszy przebieg w workflow. Faktura jest zwykle odsyłana do poprawy lub anulowania, co rozpoczyna pętlę poprawek.
Dlaczego to ważne

Analiza odrzuconych faktur pomaga wykryć przyczyny poprawek, takie jak błędne kodowanie, naruszenie zasad lub problemy z danymi na wcześniejszych etapach. Ograniczenie liczby odrzuceń zwiększa sprawność procesu.

Skąd pobrać

Jest to jawnie rejestrowana czynność w historii akceptacji faktury lub dzienniku workflow, często wraz z podanym powodem odrzucenia.

Rejestrowanie

Należy znaleźć zdarzenie zarejestrowane po wybraniu przez osobę akceptującą opcji „Reject” lub „Deny” w workflow.

Typ zdarzenia explicit
Otrzymano fakturę
Oznacza otrzymanie faktury lub jej utworzenie w systemie. To zdarzenie rozpoczyna cykl obsługi faktury, niezależnie od sposobu jej wprowadzenia, na przykład ręcznie, przez portal dostawcy lub za pomocą OCR.
Dlaczego to ważne

To zdarzenie jest niezbędne do pomiaru całkowitego czasu obsługi faktury od początku do końca. Stanowi punkt odniesienia przy ocenie obciążenia pracą i początkowych opóźnień.

Skąd pobrać

Zdarzenie jest zwykle rejestrowane na podstawie znacznika czasu utworzenia rekordu faktury lub pierwszego wpisu w dzienniku dokumentów.

Rejestrowanie

Należy użyć daty i godziny utworzenia głównego obiektu faktury lub rachunku dostawcy w systemie źródłowym.

Typ zdarzenia explicit
Uzgodniono fakturę
Oznacza pomyślne uzgodnienie faktury z zamówieniem zakupu oraz, jeśli dotyczy, z potwierdzeniem odbioru towaru. Ten krok, wykonywany automatycznie lub ręcznie, potwierdza zgodność ilości i cen na fakturze z zamówionymi i otrzymanymi towarami.
Dlaczego to ważne

To ważny etap przetwarzania bezpośredniego. Duży odsetek faktur uzgodnionych za pierwszym razem świadczy o sprawnym przebiegu wcześniejszych etapów zakupowych.

Skąd pobrać

Zdarzenie jest zwykle rejestrowane jako zmiana statusu lub osobny wpis w historii transakcji po pomyślnym zakończeniu weryfikacji uzgodnienia.

Rejestrowanie

Należy znaleźć zdarzenie lub zmianę statusu wskazującą, że uzgodnienie faktury zakończyło się statusem „Passed”, „Matched” lub „Reconciled”.

Typ zdarzenia explicit
Wykryto rozbieżność przy uzgadnianiu
Zdarzenie występuje, gdy system lub użytkownik wykryje niezgodność między fakturą, zamówieniem zakupu lub potwierdzeniem odbioru towaru. Rozbieżności, na przykład różnice w cenie lub ilości, zwykle wstrzymują fakturę i wymagają ręcznej interwencji.
Dlaczego to ważne

Śledzenie tych zdarzeń jest podstawą analizy przyczyn opóźnień i poprawek. Pomaga wykryć problemy z poprawnością faktur dostawców lub z wewnętrznym procesem zakupowym.

Skąd pobrać

Zdarzenie można wywnioskować ze zmiany statusu wskazującej niepowodzenie uzgodnienia lub z automatycznego nałożenia przez system blokady związanej z rozbieżnością.

Rejestrowanie

Należy zarejestrować znacznik czasu zmiany statusu uzgodnienia faktury na „Failed” lub „Discrepancy” albo nałożenia blokady z powodu rozbieżności.

Typ zdarzenia inferred
Zaakceptowano fakturę
Oznacza, że wszystkie wymagane osoby zaakceptowały fakturę w workflow. Ten etap pozwala zaksięgować fakturę i przekazać ją do dalszej obsługi płatności.
Dlaczego to ważne

To ważny etap kończący weryfikację i akceptację. Jest niezbędny do pomiaru czasu akceptacji i sprawdzenia zgodności z zasadami autoryzacji.

Skąd pobrać

Zdarzenie jest jawnie rejestrowane w historii akceptacji lub dzienniku workflow po uzyskaniu ostatecznej akceptacji.

Rejestrowanie

Należy użyć znacznika czasu ostatecznej akceptacji z historii akceptacji faktury lub workflow.

Typ zdarzenia explicit
Zaksięgowano fakturę w księdze głównej
Oznacza formalne zdarzenie księgowe, w ramach którego zaakceptowana faktura zostaje ujęta w księdze głównej. Powstaje zobowiązanie finansowe, a faktura przechodzi ze statusu w trakcie obsługi do statusu gotowej do płatności.
Dlaczego to ważne

To ważny etap finansowy, który potwierdza oficjalne ujęcie zobowiązania. Opóźnienia przed tym krokiem mogą wpłynąć na zamknięcie okresu finansowego i poprawność raportowania.

Skąd pobrać

Jest to jawne zdarzenie transakcyjne rejestrowane w modułach finansowych systemu.

Rejestrowanie

Należy użyć daty księgowania dokumentu finansowego utworzonego na podstawie faktury.

Typ zdarzenia explicit
Zrealizowano płatność
Oznacza końcowy etap procesu, w którym płatność zostaje zrealizowana, a zobowiązanie z tytułu faktury rozliczone. Zdarzenie potwierdza przekazanie środków dostawcy.
Dlaczego to ważne

To pomyślne zakończenie cyklu Purchase to Pay dla faktury. Jest to zdarzenie, na podstawie którego mierzy się terminowość płatności i całkowity czas procesu.

Skąd pobrać

Zdarzenie jest rejestrowane na podstawie daty księgowania dokumentu płatności, który rozlicza fakturę.

Rejestrowanie

Należy użyć daty rozliczenia lub daty płatności z dokumentu finansowego rozliczającego otwartą pozycję dostawcy.

Typ zdarzenia explicit
Anulowano fakturę
Faktura została unieważniona, storniowana lub anulowana i nie będzie dalej obsługiwana ani opłacona. Jest to końcowy status błędnej lub zduplikowanej faktury.
Dlaczego to ważne

Śledzenie anulowań pomaga wykryć problemy z jakością danych, duplikaty i inne błędy na wcześniejszych etapach. Wysoki odsetek anulowań może wskazywać na problemy z fakturami dostawców lub kontrolami wewnętrznymi.

Skąd pobrać

Jest to jawna zmiana statusu rekordu faktury lub utworzenie powiązanego dokumentu storna.

Rejestrowanie

Należy znaleźć znacznik czasu zmiany statusu faktury na „Canceled” lub „Voided” albo zaksięgowania dokumentu storna.

Typ zdarzenia explicit
Faktura stała się przeterminowana
Zdarzenie obliczane, które występuje, gdy bieżąca data przekracza termin płatności netto faktury, a faktura pozostaje nieopłacona. Termin płatności wynika z daty faktury i warunków płatności dostawcy.
Dlaczego to ważne

To zdarzenie bezpośrednio wskazuje opóźnione płatności, które mogą pogorszyć relacje z dostawcami i wiązać się z karami. Jest niezbędne do monitorowania i poprawy terminowości płatności.

Skąd pobrać

Nie jest to jawne zdarzenie systemowe. Należy je obliczyć, porównując datę płatności, a w przypadku nieopłaconej faktury bieżącą datę, z terminem płatności faktury.

Rejestrowanie

Zdarzenie należy obliczyć za pomocą wyrażenia IF(payment_date > due_date, due_date + 1 day, NULL) dla opłaconych faktur albo IF(current_date > due_date, due_date + 1 day, NULL) dla otwartych faktur.

Typ zdarzenia calculated
Nałożono blokadę płatności
Na fakturę nałożono blokadę, która uniemożliwia jej opłacenie nawet po akceptacji. Blokada może być nakładana automatycznie na podstawie reguł systemowych lub ręcznie, na przykład z powodu sporu z dostawcą.
Dlaczego to ważne

Blokady płatności często powodują opóźnienia i utratę rabatów. Ustalenie, kiedy i dlaczego są nakładane, pomaga zwiększyć odsetek płatności realizowanych w terminie.

Skąd pobrać

Zdarzenie jest zwykle rejestrowane jako osobny status lub flaga w rekordzie faktury albo wierszach faktury.

Rejestrowanie

Należy zarejestrować zdarzenie nałożenia kodu blokady płatności lub statusu wstrzymania na fakturę albo jej wiersze.

Typ zdarzenia explicit
Poprawiono fakturę
Oznacza ręczną zmianę lub poprawkę faktury, często po jej odrzuceniu albo w celu usunięcia wykrytego błędu. To odstępstwo od standardowego procesu bez ręcznej obsługi.
Dlaczego to ważne

Śledzenie poprawek ujawnia nieefektywne działania i ukryte koszty. Wiedza o tym, dlaczego faktury są zmieniane, pomaga zaplanować konkretne usprawnienia procesu i szkolenia.

Skąd pobrać

Zdarzenie zwykle można wywnioskować z dzienników zmian lub ścieżek audytu, które rejestrują modyfikacje ważnych pól faktury po jej wstępnym wprowadzeniu.

Rejestrowanie

Należy pobrać znaczniki czasu z dzienników audytu wskazujące zmianę danych faktury, zwłaszcza po jej odrzuceniu lub wstrzymaniu.

Typ zdarzenia inferred
Przekazano fakturę do akceptacji
Oznacza formalne przekazanie faktury do workflow akceptacji po zakończeniu wstępnej weryfikacji i uzgadniania. Zgodnie z ustawionymi regułami biznesowymi faktura trafia do wyznaczonych osób akceptujących.
Dlaczego to ważne

Ten etap rozpoczyna podproces akceptacji. Pomiar czasu od tego zdarzenia do ostatecznej akceptacji pozwala ocenić sprawność workflow i wykryć wąskie gardła.

Skąd pobrać

W systemach z silnikiem workflow jest to jawnie rejestrowane zdarzenie. Można je też wywnioskować ze zmiany statusu na „Pending Approval”.

Rejestrowanie

Należy zarejestrować znacznik czasu rozpoczęcia workflow lub zmiany statusu faktury wskazującej, że oczekuje na akceptację.

Typ zdarzenia explicit
Rozwiązano rozbieżność
Oznacza moment, w którym wcześniej wykryta rozbieżność przy uzgadnianiu została ręcznie zbadana i rozwiązana. Faktura może wtedy przejść do kolejnego kroku, na przykład akceptacji lub ponownego uzgodnienia.
Dlaczego to ważne

Czas rozwiązywania rozbieżności ma duży wpływ na całkowity czas obsługi faktury. Analiza tego etapu pomaga ocenić nakład pracy i czas potrzebny na obsługę wyjątków.

Skąd pobrać

Zdarzenie często można wywnioskować z pierwszej czynności użytkownika, która usuwa blokadę uzgodnienia lub umożliwia ponowne przetworzenie faktury po nieudanym uzgodnieniu.

Rejestrowanie

Należy znaleźć zdarzenie, w którym zwolniono blokadę związaną z uzgadnianiem lub pomyślnie uzgodniono fakturę po wcześniejszym niepowodzeniu.

Typ zdarzenia inferred
Wprowadzono fakturę
Oznacza zakończenie wstępnego wprowadzania danych. Szczegóły faktury zostały wpisane lub zeskanowane, ale dokument nie został jeszcze zaksięgowany ani przekazany do formalnej akceptacji. Faktura często ma tymczasowy status „wstrzymana” lub „robocza”.
Dlaczego to ważne

Analiza czasu między otrzymaniem a wprowadzeniem faktury pomaga wykryć zaległości na etapie wprowadzania danych. Może też pokazać skuteczność automatycznego odczytu danych.

Skąd pobrać

Zdarzenie często można wywnioskować z zapisania faktury ze statusem roboczym lub wstrzymanym, zanim zostanie przekazana do workflow.

Rejestrowanie

Należy zarejestrować znacznik czasu zmiany statusu faktury z nowego na zapisany, wstrzymany lub roboczy.

Typ zdarzenia inferred
Zaplanowano płatność
Zaksięgowana faktura zostaje wybrana i dodana do propozycji płatności lub paczki płatności. Ten krok umieszcza fakturę w kolejce do realizacji płatności w określonym dniu, ale nie oznacza jeszcze faktycznego przekazania środków.
Dlaczego to ważne

To zdarzenie pokazuje końcowy etap procesu. Opóźnienia między zaksięgowaniem a zaplanowaniem płatności mogą prowadzić do utraty rabatów i opóźnionych płatności.

Skąd pobrać

Zdarzenie jest zwykle rejestrowane po dodaniu faktury do przebiegu płatności, propozycji płatności lub dziennika płatności.

Rejestrowanie

Należy znaleźć datę utworzenia propozycji płatności lub rekordu paczki płatności zawierającej fakturę.

Typ zdarzenia explicit
Zwolniono blokadę płatności
Oznacza usunięcie wcześniej nałożonej blokady płatności, dzięki czemu faktura ponownie kwalifikuje się do zapłaty. Wskazuje, że rozwiązano problem, który spowodował blokadę.
Dlaczego to ważne

Czas od nałożenia do zwolnienia blokady oznacza opóźnienie w procesie. Analiza tego okresu pomaga wykryć wąskie gardła w rozwiązywaniu problemów.

Skąd pobrać

Zdarzenie jest rejestrowane po usunięciu statusu lub flagi blokady płatności z rekordu faktury.

Rejestrowanie

Należy zarejestrować zdarzenie usunięcia kodu blokady płatności lub statusu wstrzymania albo zmiany statusu na odblokowany.

Typ zdarzenia explicit
Zalecane Opcjonalne

Instrukcje ekstrakcji danych

Jak przygotować dane do process mining.

Metody ekstrakcji zależą od systemu. Szczegółowe instrukcje znajdą Państwo w

naszym przewodniku ETL   lub   wybierz konkretny proces i system.

Jak zacząć?

Aby rozpocząć ekstrakcję danych, wybierz instrukcję dla używanego systemu. Można też skorzystać z tego ogólnego szablonu jako punktu odniesienia dla dowolnego źródła danych.

Usprawnij obsługę faktur i zwiększ efektywność procesu P2P

Odkryj problemy w procesie, ogranicz koszty i przyspiesz obsługę faktur.

Rozpocznij okres próbny

Karta kredytowa nie jest wymagana. Konfiguracja zajmuje tylko 5 minut.