Szablon danych do procesu obsługi faktur zobowiązań
Szablon danych do procesu obsługi faktur zobowiązań
To ogólny szablon danych do process mining dla procesu Obsługa faktur zobowiązań. Aby uzyskać dokładniejsze wskazówki, skorzystaj z szablonów dla konkretnych systemów.
Wybierz konkretny system- Uniwersalna struktura danych dla każdego systemu obsługi zobowiązań
- Zalecane atrybuty do szczegółowej analizy
- Najważniejsze czynności, które warto rejestrować, aby uzyskać pełny obraz procesu
Atrybuty procesu obsługi faktur zobowiązań
| Nazwa | Opis | ||
|---|---|---|---|
| Czas zdarzenia EventTime | Znacznik czasu wskazujący dokładną datę i godzinę wystąpienia działania lub zdarzenia. | ||
| Opis Czas zdarzenia wskazuje dokładny moment wykonania danego działania w cyklu obsługi faktury. Każde działanie, od „Otrzymano fakturę” po „Rozliczono fakturę”, ma przypisany znacznik czasu. Ten atrybut jest niezbędny do analizy wyników procesu. Pozwala obliczyć czas między działaniami, na przykład czas zatwierdzania i płatności, oraz całkowity czas obsługi każdej faktury od początku do końca. Analiza tych okresów pomaga wykrywać wąskie gardła, mierzyć wyniki względem umów o gwarantowanym poziomie usług (SLA) i wskazywać możliwości przyspieszenia procesu. Umożliwia też uporządkowanie zdarzeń chronologicznie i dokładne odtworzenie przebiegu procesu. Dlaczego to ważne Jest niezbędny do obliczania czasu realizacji, wykrywania wąskich gardeł i analizy chronologicznej kolejności zdarzeń w procesie. Skąd pobrać Można go znaleźć w dziennikach systemowych, polach daty utworzenia lub zmiany transakcji albo rekordach znaczników czasu zdarzeń powiązanych z dokumentami faktur. Przykłady 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2023-12-01T09:12:45Z | |||
| Identyfikator faktury InvoiceId | Unikalny identyfikator dokumentu faktury od dostawcy. Służy jako główny identyfikator sprawy, który pozwala śledzić cały przebieg obsługi faktury. | ||
| Opis Identyfikator faktury to unikalny kod alfanumeryczny przypisany do każdej faktury otrzymanej od dostawcy. Jest głównym punktem odniesienia dla wszystkich działań i danych dotyczących danej faktury, od jej otrzymania po płatność i rozliczenie. W process mining identyfikator faktury ma podstawowe znaczenie. Pełni funkcję identyfikatora sprawy (Case ID), dzięki czemu oprogramowanie może połączyć zdarzenia, takie jak „Otrzymano fakturę”, „Zatwierdzono” i „Opłacono”, w spójny przebieg procesu dla pojedynczej faktury. Umożliwia to analizę wariantów procesu, czasu realizacji i wąskich gardeł dla każdej faktury oraz pokazuje, jak przebiega jej obsługa. Dlaczego to ważne To najważniejszy atrybut, ponieważ łączy wszystkie powiązane etapy procesu w jedną sprawę i umożliwia analizę oraz wizualizację procesu od początku do końca. Skąd pobrać Zwykle znajduje się w danych nagłówka faktury lub tabelach transakcji zobowiązań w systemie źródłowym. Przykłady INV-9876547300015298SI-2023-04-112 | |||
| Nazwa działania ActivityName | Nazwa kroku procesu biznesowego lub zdarzenia dotyczącego faktury. | ||
| Opis Nazwa działania opisuje konkretną czynność, zmianę statusu lub etap w cyklu obsługi faktury. Każde zarejestrowane zdarzenie dotyczące faktury, takie jak „Zweryfikowano fakturę”, „Przekazano do zatwierdzenia” lub „Zrealizowano płatność”, ma odrębną nazwę działania. Ten atrybut stanowi podstawę mapy procesu, na której każda unikalna wartość jest osobnym węzłem wizualnego przebiegu procesu. Analiza kolejności, częstotliwości i czasu trwania działań to podstawa process mining. Pomaga wykryć typowe ścieżki, odstępstwa i powtarzające się poprawki oraz zrozumieć, jak proces przebiega w praktyce. Dlaczego to ważne Określa kroki na mapie procesu, umożliwiając wizualizację i analizę przebiegu procesu, wąskich gardeł oraz różnic między jego wariantami. Skąd pobrać Zwykle pochodzi z kodów transakcji, dzienników zdarzeń, pól zmiany statusu lub zapisów konkretnych działań użytkownika w systemie źródłowym. Przykłady Zatwierdzono fakturęZablokowano fakturęZrealizowano płatność | |||
| 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 Znacznik czasu ostatniej aktualizacji danych wskazuje, kiedy dane zostały ostatnio wyodrębnione z systemu źródłowego i załadowane do środowiska process mining. Nie określa, kiedy wystąpiło zdarzenie biznesowe, lecz informuje o aktualności analizowanych danych. Ten atrybut ma znaczenie dla zarządzania danymi i pozwala użytkownikom ocenić, na ile aktualne są dostępne informacje. Pomaga potwierdzić, że analiza opiera się na bieżących danych, a także monitorować stan i częstotliwość działania potoku danych. Dzięki temu osoby korzystające z dashboardów i analiz procesów wiedzą, jak świeże są dane, na których opierają decyzje. Dlaczego to ważne Ma znaczenie dla zarządzania danymi i pozwala użytkownikom ocenić ich aktualność, co zwiększa zaufanie do wyników analizy. Skąd pobrać Ten znacznik czasu jest zwykle generowany i dodawany podczas procesu wyodrębniania, przekształcania i ładowania danych (ETL). Przykłady 2024-01-20T04:00:00Z2024-01-21T04:00:00Z2024-01-22T04:00:00Z | |||
| System źródłowy SourceSystem | System, z którego wyodrębniono dane. | ||
| Opis Ten atrybut wskazuje pierwotny system IT, w którym wygenerowano lub zarejestrowano dane o zdarzeniu, na przykład system ERP, system zarządzania dokumentami lub narzędzie workflow. Jeśli w obsługę zobowiązań zaangażowanych jest kilka systemów, pole to pomaga ustalić, z którego z nich pochodzi dane działanie. Analiza danych według systemu źródłowego pomaga zrozumieć fragmentację procesu i problemy z integracją danych. Może ujawnić, czy opóźnienia lub problemy wiążą się z przekazywaniem pracy między systemami. Jest też ważna dla zarządzania danymi i ich weryfikacji, ponieważ pozwala sprawdzić, czy obraz procesu prawidłowo uwzględnia dane z każdego systemu. Dlaczego to ważne Informuje o pochodzeniu danych, co pomaga w ich weryfikacji, rozwiązywaniu problemów i analizie różnic w przebiegu procesu między systemami. Skąd pobrać Zwykle jest to stała wartość dodawana podczas wyodrębniania danych lub dostępna w nagłówkach dzienników systemowych. Przykłady ERP_PRODSAP_ECC_100Oracle_Fusion | |||
| Kod spółki CompanyCode | Identyfikator podmiotu prawnego lub spółki, która przetwarza fakturę. | ||
| Opis Kod spółki to unikalny identyfikator odrębnego podmiotu prawnego lub spółki w organizacji. Faktury są przetwarzane i księgowane w imieniu konkretnej spółki. Ten atrybut jest podstawowym wymiarem analizy porównawczej w organizacjach obejmujących wiele podmiotów. Umożliwia porównywanie wyników procesu obsługi zobowiązań w różnych spółkach, jednostkach zależnych i jednostkach biznesowych. Analiza może wykazać, które podmioty działają sprawniej, osiągają wyższy poziom automatyzacji lub częściej blokują płatności. Ułatwia to ujednolicanie dobrych praktyk i wykrywanie problemów charakterystycznych dla danego regionu lub podmiotu. Dlaczego to ważne Umożliwia porównywanie procesów w różnych podmiotach prawnych i jednostkach biznesowych, co pomaga ujednolicać praktyki i wykrywać lokalne problemy. Skąd pobrać Znajduje się w nagłówku dokumentu finansowego lub dokumentu transakcji faktury i wskazuje podmiot księgujący. Przykłady 1000US01DE01 | |||
| Kwota faktury InvoiceAmount | Łączna wartość faktury w walucie oryginalnej transakcji. | ||
| Opis Kwota faktury oznacza łączną wartość brutto faktury przesłanej przez dostawcę. To ważny wskaźnik finansowy dla każdej sprawy. Ten atrybut jest szeroko wykorzystywany w analizach finansowych i operacyjnych. Umożliwia filtrowanie procesów według wartości faktur, na przykład osobną analizę faktur o wysokiej wartości, wskazywanie wąskich gardeł w zatwierdzaniu faktur przekraczających określony próg oraz obliczanie finansowych skutków nieefektywności procesu. Można go użyć do oszacowania wartości zablokowanych faktur lub ustalenia priorytetów automatyzacji dla dużej liczby faktur o niskiej wartości. To podstawowy wymiar niemal każdego dashboardu zobowiązań. Dlaczego to ważne Umożliwia analizę skutków finansowych, na przykład oszacowanie wartości zablokowanych płatności, oraz pomaga ustalać priorytety faktur według ich wartości. Skąd pobrać Zazwyczaj znajduje się w nagłówku lub wierszach danych transakcji faktury. Przykłady 1500.7525000.00345.50 | |||
| Nazwa dostawcy VendorName | Nazwa dostawcy, który przesłał fakturę. | ||
| Opis Nazwa dostawcy wskazuje jego nazwę prawną lub handlową. Ten atrybut dostarcza ważnego kontekstu biznesowego dla każdej faktury. Podział procesu według dostawcy pozwala ocenić wyniki i relacje z poszczególnymi dostawcami. Pomaga odpowiedzieć na pytania: „W przypadku których dostawców zatwierdzanie trwa najdłużej?”, „Czy faktury od niektórych dostawców często zawierają rozbieżności?” oraz „Czy skutecznie wykorzystujemy rabaty za wcześniejszą płatność u naszych głównych dostawców?”. Taka analiza jest ważna dla zakupów i zarządzania relacjami z dostawcami. Dlaczego to ważne Umożliwia analizę wyników według dostawcy, pomagając wykryć problemy w relacjach z dostawcami, ocenić zgodność z warunkami płatności i porównać przebieg procesu dla poszczególnych dostawców. Skąd pobrać Znajduje się w tabelach danych podstawowych dostawców i jest powiązany z danymi transakcji faktur za pomocą identyfikatora dostawcy. Przykłady Globalne artykuły biuroweInnowacyjne rozwiązania technologiczneZaawansowana logistyka | |||
| Nazwa użytkownika UserName | Nazwa lub identyfikator użytkownika, który wykonał daną czynność dotyczącą faktury. | ||
| Opis Nazwa użytkownika wskazuje pracownika lub użytkownika systemu odpowiedzialnego za dany etap procesu, na przykład wprowadzenie, zatwierdzenie lub zaksięgowanie faktury. W przypadku czynności zautomatyzowanych może to być identyfikator użytkownika systemowego lub wsadowego. Ten atrybut pozwala analizować proces z perspektywy osób, które go wykonują. Służy do badania rozkładu obciążenia pracą i wyników poszczególnych osób lub zespołów, a także do wskazywania potrzeb szkoleniowych. Analiza czynności według użytkownika pomaga wykrywać pętle poprawek związane z konkretnymi osobami, ustalać, na którym etapie zatrzymują się zatwierdzenia, oraz sprawdzać prawidłowy podział obowiązków. To ważny atrybut pozwalający zrozumieć rolę ludzi w procesie obsługi zobowiązań. Dlaczego to ważne Umożliwia analizę wyników zespołów i poszczególnych osób oraz rozkładu obciążenia pracą, a także pomaga wskazywać potrzeby szkoleniowe i problemy ze zgodnością. Skąd pobrać Zazwyczaj znajduje się w dziennikach zdarzeń lub w polach „Zmienione przez” / „Utworzone przez” w tabelach transakcji. Przykłady jdoeasmithBATCH_USER | |||
| Numer zamówienia zakupu PurchaseOrderNumber | Unikalny identyfikator zamówienia zakupu (PO) powiązanego z fakturą. | ||
| Opis Numer zamówienia zakupu to identyfikator dokumentu, który pierwotnie zatwierdził zakup towarów lub usług od dostawcy. Faktury mogą być powiązane z zamówieniem zakupu lub nie. Ten atrybut ma zasadnicze znaczenie dla analizy procesu uzgadniania faktur. Pozwala rozróżnić faktury powiązane z zamówieniem zakupu od tych, które nie są z nim powiązane. Zwykle przechodzą one różnymi ścieżkami procesu. Analiza może obejmować sprawność uzgadniania trójstronnego (zamówienie zakupu, potwierdzenie odbioru towarów i faktura), przyczyny niezgodności oraz wskaźnik KPI skuteczności uzgodnień przy pierwszej próbie. Brak numeru zamówienia zakupu na fakturze, która powinna go zawierać, często wskazuje na problem ze zgodnością procesu. Dlaczego to ważne Niezbędny do analizy sprawności uzgadniania faktur, rozróżniania procesów obsługi faktur powiązanych z zamówieniem zakupu i bez takiego powiązania oraz wykrywania problemów ze zgodnością. Skąd pobrać Znajduje się w danych transakcji faktur, często w polu referencyjnym łączącym fakturę z modułem zakupowym. Przykłady 4500017545PO-2023-10-005789123 | |||
| Termin płatności faktury InvoiceDueDate | Data, do której należy opłacić fakturę zgodnie z warunkami płatności. | ||
| Opis Termin płatności faktury to wyliczona data, do której należy zapłacić dostawcy, aby płatność została uznana za terminową i nie wiązała się z opłatami ani karami za opóźnienie. Zazwyczaj wynika z daty faktury i uzgodnionych warunków płatności, na przykład 30 dni. Ten atrybut jest niezbędny do pomiaru terminowości płatności. Stanowi podstawę obliczania wskaźnika KPI terminowości płatności i wykrywania opóźnień. Porównanie terminu płatności z faktyczną datą zapłaty pozwala analizować terminowość, poprawiać relacje z dostawcami, unikać kar i lepiej zarządzać przepływami pieniężnymi. Dlaczego to ważne Jest niezbędny do pomiaru terminowości płatności, zarządzania przepływami pieniężnymi i unikania kar za opóźnienia. Skąd pobrać Datę tę często wylicza system źródłowy na podstawie daty faktury i warunków płatności, a następnie zapisuje w nagłówku faktury. Przykłady 2023-11-252023-12-152024-01-30 | |||
| Czy zautomatyzowano IsAutomated | Wskaźnik informujący, czy czynność wykonał automatycznie system, czy użytkownik. | ||
| Opis Ten atrybut logiczny wskazuje, czy dany etap procesu wykonał użytkownik systemowy, na przykład automatyzacja, workflow lub zadanie wsadowe, czy człowiek. Pozwala rozróżnić czynności ręczne i zautomatyzowane. Analiza tego atrybutu jest niezbędna do oceny poziomu automatyzacji procesu obsługi zobowiązań i wyników inicjatyw transformacji cyfrowej. Ułatwia obliczanie wskaźnika przetwarzania bezobsługowego (STP), ponieważ pozwala wskazać faktury obsłużone bez ręcznej ingerencji. Porównanie ścieżek zautomatyzowanych i ręcznych może uzasadnić dalsze inwestycje w automatyzację, pokazując oszczędności czasu i kosztów. Dlaczego to ważne Umożliwia pomiar poziomu automatyzacji, na przykład wskaźnika przetwarzania bezobsługowego, oraz ocenę wpływu automatyzacji na sprawność procesu. Skąd pobrać Często ustala się to, sprawdzając, czy pole „UserName” dla danej czynności zawiera znany identyfikator użytkownika systemowego lub wsadowego. Przykłady truefalse | |||
| Data płatności PaymentDate | Data faktycznego wykonania płatności za fakturę. | ||
| Opis Data płatności to znacznik czasu wskazujący, kiedy środki za daną fakturę zostały przekazane dostawcy. To ważny etap, który często oznacza koniec głównego przebiegu procesu. W analizie process mining datę tę porównuje się z terminem płatności faktury, aby ustalić, czy płatność nastąpiła przed terminem, w terminie czy po terminie. Jest ona podstawą obliczania ważnych wskaźników KPI, takich jak terminowość płatności, oraz analizy możliwości skorzystania ze skonta za wcześniejszą zapłatę. Różnica między zatwierdzeniem faktury a datą płatności może też ujawnić nieefektywności w realizacji płatności lub zarządzaniu środkami. Dlaczego to ważne Niezbędna do obliczania terminowości płatności, analizy zachowań płatniczych i wykrywania możliwości skorzystania ze skonta za wcześniejszą zapłatę. Skąd pobrać Znajduje się w danych płatności lub dokumentu rozliczeniowego, powiązanych z pierwotną transakcją faktury. Przykłady 2023-11-242023-12-202024-01-28 | |||
| Przyczyna blokady BlockingReason | Kod lub opis wyjaśniający, dlaczego faktura została zablokowana przed płatnością. | ||
| Opis Przyczyna blokady to kod lub opis wyjaśniający, dlaczego faktura została celowo zatrzymana przed etapem płatności. Typowe przyczyny to niezgodność ilości lub ceny, brak potwierdzenia odbioru towarów albo wymagana kontrola jakości. Ten atrybut jest niezbędny do analizy przyczyn wyjątków i poprawek. Analiza częstotliwości i skutków poszczególnych przyczyn blokad pozwala wskazać najczęstsze źródła nieefektywności w procesie obsługi zobowiązań. Na tej podstawie można zaplanować konkretne usprawnienia, takie jak poprawa dokładności zamówień zakupu u dostawców lub uproszczenie procesu potwierdzania odbioru towarów. Ograniczenie blokad płatności pomaga zwiększyć wskaźnik przetwarzania bezobsługowego (STP). Dlaczego to ważne Niezbędna do analizy przyczyn blokad płatności oraz wskazywania głównych źródeł nieefektywności i poprawek w procesie. Skąd pobrać Znajduje się w dokumencie faktury lub powiązanej tabeli statusów. Często jest uzupełniana po wystąpieniu czynności „Zablokowano”. Przykłady Niezgodność cenyNiezgodność ilościBrak potwierdzenia odbioru towarów | |||
| Waluta faktury InvoiceCurrency | Kod waluty, w której wyrażono kwotę faktury, na przykład USD, EUR lub GBP. | ||
| Opis Waluta faktury określa jednostkę pieniężną, w której podano kwotę faktury. Ma to szczególne znaczenie dla międzynarodowych organizacji współpracujących z dostawcami z różnych krajów. W analizie ten atrybut jest niezbędny do prawidłowej interpretacji kwoty faktury i wykonywania dokładnych obliczeń finansowych. Umożliwia filtrowanie procesu według waluty, aby analizować różnice regionalne lub problemy związane z konkretną walutą. Po połączeniu z danymi o kursach wymiany pozwala przeliczyć wartości finansowe na jedną walutę raportową i prowadzić spójną analizę globalną. Dlaczego to ważne Zapewnia kontekst niezbędny do prawidłowej analizy finansowej i podziału procesów według waluty w organizacjach działających na wielu rynkach. Skąd pobrać Zazwyczaj znajduje się w nagłówku tabeli transakcji faktur, obok kwoty faktury. Przykłady USDEURGBP | |||
| Warunki płatności PaymentTerms | Uzgodnione z dostawcą warunki płatności faktury, obejmujące termin zapłaty i możliwość uzyskania skonta. | ||
| Opis Warunki płatności określają zasady opłacania faktury. Obejmują między innymi liczbę dni do terminu płatności, na przykład 30 dni, oraz ewentualne skonto za wcześniejszą zapłatę, na przykład 2% przy płatności w ciągu 10 dni. Ten atrybut zapewnia kontekst niezbędny do analizy wyników finansowych. Służy do obliczania terminu płatności faktury i wykrywania możliwości skorzystania ze skonta za wcześniejszą zapłatę. Analiza wyników procesu według warunków płatności pozwala sprawdzić, czy długi czas obsługi wewnętrznej powoduje systematyczną utratę takich możliwości. Dzięki temu można bezpośrednio powiązać sprawność procesu z oszczędnościami. Dlaczego to ważne Pozwala obliczyć termin płatności faktury i analizować, jak często udaje się skorzystać ze skonta za wcześniejszą zapłatę, łącząc sprawność procesu z oszczędnościami. Skąd pobrać Zazwyczaj pochodzi z danych podstawowych dostawcy i jest kopiowany do nagłówka transakcji faktury podczas jej tworzenia. Przykłady 30 dni netto2% przy płatności w ciągu 10 dni, 30 dni netto60 dni netto | |||
Czynności w procesie obsługi faktur zobowiązań
| Działanie | Opis | ||
|---|---|---|---|
| Otrzymano fakturę | To zdarzenie oznacza wprowadzenie faktury dostawcy do systemu. Dane mogą zostać wpisane ręcznie, odczytane ze skanu za pomocą optycznego rozpoznawania znaków (OCR) lub przekazane elektronicznie przez EDI. | ||
| Dlaczego to ważne To główny punkt rozpoczęcia procesu. Analiza czasu od tego zdarzenia do kolejnych zdarzeń pokazuje całkowity czas obsługi i pozwala wykryć opóźnienia na jej początkowym etapie. Skąd pobrać Zdarzenie to zwykle rejestruje się na podstawie znacznika czasu utworzenia głównego rekordu faktury lub rachunku dostawcy w systemie. Rejestrowanie Należy użyć daty utworzenia rekordu nagłówka faktury. Typ zdarzenia explicit | |||
| Przekazano do zatwierdzenia | Faktura zostaje formalnie przekazana do workflow, w którym jedna lub więcej upoważnionych osób ją sprawdza i zatwierdza. To początek podprocesu zatwierdzania. | ||
| Dlaczego to ważne To punkt początkowy pomiaru czasu zatwierdzania. Pozwala oddzielić czas przetwarzania danych od czasu oczekiwania na decyzję kierownictwa. Skąd pobrać Zdarzenie rejestruje się, gdy status faktury zmienia się na „Oczekuje na zatwierdzenie” lub gdy faktura trafia do systemu zarządzania workflow. Rejestrowanie Należy znaleźć zdarzenie, w którym status faktury wskazuje rozpoczęcie workflow zatwierdzania. Typ zdarzenia explicit | |||
| Rozliczono fakturę | To końcowe uzgodnienie, w ramach którego płatność zostaje przypisana do faktury, a pozycja formalnie zamknięta w księdze pomocniczej zobowiązań. W niektórych przypadkach oznacza również rozliczenie płatności przez bank. | ||
| Dlaczego to ważne To ostatnie działanie, które oznacza pomyślne zakończenie procesu. Czas od otrzymania faktury do jej rozliczenia odpowiada całkowitemu czasowi obsługi od początku do końca. Skąd pobrać Zdarzenie odczytuje się z pola daty rozliczenia w rekordzie finansowym faktury. Pole jest uzupełniane po przypisaniu płatności. Rejestrowanie Należy użyć daty rozliczenia przypisanej do pozycji faktury w księdze finansowej. Typ zdarzenia explicit | |||
| Uzgodniono fakturę | Polega na powiązaniu faktury z dokumentami pomocniczymi, takimi jak zamówienia zakupu (PO) lub potwierdzenia odbioru towaru (GR). Potwierdza zgodność kwot, ilości i pozycji na fakturze z zamówieniem i otrzymanym towarem. | ||
| Dlaczego to ważne To ważny etap weryfikacji faktur opartych na zamówieniu zakupu. Analiza skuteczności i czasu uzgadniania pomaga ocenić poziom automatyzacji oraz wykryć problemy związane z dostawcami lub materiałami. Skąd pobrać Zdarzenie to zwykle rejestruje się po pomyślnym powiązaniu numeru PO lub GR z pozycjami faktury, często przez aktualizację pola statusu uzgadniania. Rejestrowanie Należy zapisać znacznik czasu zmiany statusu uzgadniania faktury na „Uzgodniono” lub „Pomyślnie”. Typ zdarzenia explicit | |||
| Zaksięgowano fakturę | Zatwierdzona faktura zostaje oficjalnie ujęta w księdze głównej, tworząc zobowiązanie finansowe firmy. Ta operacja księgowa formalnie ujmuje koszt i obowiązek zapłaty. | ||
| Dlaczego to ważne Księgowanie to ważne zdarzenie finansowe. Opóźnienie między zatwierdzeniem a zaksięgowaniem może obniżyć dokładność sprawozdawczości finansowej i utrudnić kontrolę nieuregulowanych zobowiązań. Skąd pobrać To podstawowe zdarzenie finansowe, rejestrowane na podstawie daty i godziny księgowania dokumentu powiązanego z fakturą. Rejestrowanie Należy użyć pola daty księgowania z nagłówka dokumentu finansowego powiązanego z fakturą. Typ zdarzenia explicit | |||
| Zatwierdzono fakturę | Oznacza końcowe zatwierdzenie w workflow i formalną zgodę na opłacenie faktury. To ważny etap, który warunkuje przejście faktury z obsługi do płatności. | ||
| Dlaczego to ważne To działanie kończy cykl zatwierdzania. Czas do jego zakończenia stanowi istotną część całkowitego czasu obsługi faktury i często ujawnia wąskie gardła w procesie zatwierdzania. Skąd pobrać Zdarzenie rejestruje się, gdy status workflow lub dokumentu zmienia się na „Zatwierdzono” albo równoważny status końcowy. Rejestrowanie Należy zapisać znacznik czasu zarejestrowania końcowego zatwierdzenia faktury. Typ zdarzenia explicit | |||
| Zrealizowano płatność | Płatność zostaje oficjalnie zrealizowana, a środki przekazane dostawcy. Transakcja reguluje zobowiązanie powstałe w chwili zaksięgowania faktury. | ||
| Dlaczego to ważne To ważne zdarzenie przy obliczaniu odsetka płatności terminowych i wykorzystanych rabatów. Oznacza przekazanie środków i stanowi istotny etap w zarządzaniu finansami oraz relacjami z dostawcami. Skąd pobrać To jawnie rejestrowane zdarzenie finansowe, którego datę odczytuje się z transakcji dokumentu płatności utworzonego dla faktury. Rejestrowanie Należy użyć daty transakcji lub księgowania dokumentu płatności, który rozlicza fakturę. Typ zdarzenia explicit | |||
| Anulowano fakturę | Faktura zostaje unieważniona lub odwrócona po wprowadzeniu albo zaksięgowaniu, zwykle w celu poprawienia błędu lub rozwiązania sporu z dostawcą. To alternatywny, zazwyczaj niepożądany koniec procesu. | ||
| Dlaczego to ważne Anulowanie może wskazywać na błędy w procesie, takie jak duplikaty lub nieprawidłowe księgowania. Śledzenie częstotliwości i przyczyn źródłowych pomaga poprawić dokładność wprowadzania danych i jakość procesu. Skąd pobrać To jawnie rejestrowane działanie, które występuje, gdy użytkownik unieważnia fakturę lub księguje dokument korygujący. W rekordzie faktury zapisywana jest wtedy data anulowania lub odwrócenia. Rejestrowanie Należy szukać powiązania z dokumentem korygującym albo flagi anulowania i przypisanej do niej daty w rekordzie faktury. Typ zdarzenia explicit | |||
| Odrzucono fakturę | Osoba zatwierdzająca odrzuca fakturę w workflow, zatrzymując jej dalszą drogę do płatności. Odrzucona faktura zwykle wraca do wcześniejszego etapu w celu poprawy, co powoduje ponowne wykonanie części pracy. | ||
| Dlaczego to ważne Odrzucenia często prowadzą do poprawek i opóźnień. Śledzenie ich częstotliwości i przyczyn pomaga wykryć problemy z jakością danych, znajomością zasad lub zgodnością dostawców z wymaganiami. Skąd pobrać Zdarzenie jest jawnie rejestrowane jako zmiana statusu, na przykład na „Odrzucono” lub „Odmówiono”, w historii zatwierdzania albo dzienniku workflow. Rejestrowanie Należy użyć znacznika czasu z dziennika zatwierdzania, gdy fakturze nadano status „Odrzucono”. Typ zdarzenia explicit | |||
| Usunięto blokadę | Oznacza rozwiązanie problemu i usunięcie blokady lub wstrzymania płatności. Faktura została poprawiona lub wyjaśniona i może kontynuować dalszą obsługę. | ||
| Dlaczego to ważne Czas od zablokowania faktury do usunięcia blokady odpowiada czasowi wyjaśniania rozbieżności. Analiza tego okresu pomaga wykryć nieefektywne działania związane z obsługą wyjątków. Skąd pobrać Zdarzenie można odczytać z dzienników systemowych lub dokumentów zmian, które rejestrują usunięcie albo dezaktywację blokady płatności. Rejestrowanie Należy zapisać znacznik czasu usunięcia kodu blokady płatności lub statusu wstrzymania z faktury. Typ zdarzenia explicit | |||
| Wykorzystano rabat za wcześniejszą płatność | Płatność zostaje zrealizowana w okresie, w którym dostawca oferuje rabat, co obniża koszty firmy. Nie jest to bezpośrednie zdarzenie systemowe, lecz informacja wyliczana na podstawie danych transakcyjnych. | ||
| Dlaczego to ważne To działanie bezpośrednio mierzy korzyść finansową wynikającą ze sprawnej obsługi zobowiązań. Wykrycie niewykorzystanych możliwości wcześniejszej płatności pozwala określić wartość usprawnień w konkretnych kwotach. Skąd pobrać To zdarzenie wyliczane przez porównanie daty realizacji płatności z warunkami płatności i datą upływu rabatu podanymi na fakturze. Rejestrowanie Obliczenie: IF Payment_Date <= Discount_Due_Date. Typ zdarzenia calculated | |||
| Wystąpiło opóźnienie płatności | Faktura zostaje opłacona po umownym terminie płatności. To zdarzenie wyliczane, które oznacza niedotrzymanie terminu płatności. | ||
| Dlaczego to ważne Opóźnione płatności mogą pogorszyć relacje z dostawcami, wiązać się z karami finansowymi i wskazywać na problemy systemowe. Pomiar tego zjawiska pomaga ocenić wyniki procesu i ryzyko związane ze zgodnością. Skąd pobrać Zdarzenie wylicza się przez porównanie daty realizacji płatności z końcowym terminem płatności podanym na fakturze. Rejestrowanie Obliczenie: IF Payment_Date > Net_Due_Date. Typ zdarzenia calculated | |||
| Zablokowano fakturę | To zdarzenie występuje, gdy faktura zostaje zablokowana i nie może przejść do płatności. Blokada jest zwykle nakładana automatycznie lub ręcznie z powodu rozbieżności wykrytych podczas uzgadniania, naruszenia zasad albo innych problemów wymagających wyjaśnienia. | ||
| Dlaczego to ważne Blokady często powodują opóźnienia płatności i zwiększają nakład pracy. Wykrycie, kiedy i dlaczego występują oraz jak często są nakładane, ma duże znaczenie dla usprawniania procesu. Skąd pobrać To jawnie rejestrowane zdarzenie, które występuje po nałożeniu blokady lub wstrzymaniu płatności. Zwykle zapisuje się je w dzienniku statusów lub historii zmian. Rejestrowanie Należy użyć znacznika czasu ustawienia kodu blokady płatności lub statusu „Wstrzymano” na fakturze. Typ zdarzenia explicit | |||
| Zaplanowano płatność | Zaksięgowana faktura zostaje wybrana i dodana do propozycji płatności lub paczki płatności. Oznacza to zamiar opłacenia faktury w najbliższym przebiegu płatności. | ||
| Dlaczego to ważne Ten etap łączy księgowanie z faktyczną płatnością. Analiza tego działania pomaga zarządzać przepływami pieniężnymi i ocenić efektywność przygotowania płatności. Skąd pobrać Zdarzenie można wywnioskować z utworzenia propozycji płatności albo dodania faktury do dziennika lub paczki płatności. Rejestrowanie Należy zapisać datę utworzenia propozycji lub paczki płatności zawierającej fakturę. Typ zdarzenia inferred | |||
| Zweryfikowano fakturę | Oznacza zakończenie wstępnej kontroli kompletności i poprawności danych faktury, zanim trafi ona do uzgadniania lub zatwierdzenia. Może to być automatyczna walidacja systemowa albo ręczna kontrola. | ||
| Dlaczego to ważne Śledzenie tego działania pomaga wykryć wąskie gardła podczas wstępnej kontroli jakości danych i ocenić efektywność czynności poprzedzających dalszą obsługę. Skąd pobrać Zdarzenie to często rejestruje się jako zmianę statusu faktury, osobny znacznik czasu walidacji albo wnioskuje o nim na podstawie zapisania rekordu bez błędów. Rejestrowanie Należy szukać zmiany statusu na „Zweryfikowano” lub osobnego zdarzenia walidacji w dzienniku zdarzeń. Typ zdarzenia explicit | |||
Instrukcje ekstrakcji danych
Metody ekstrakcji zależą od systemu. Szczegółowe instrukcje znajdą Państwo w
naszym przewodniku ETL lub wybierz konkretny proces i system.
Gotowi do rozpoczęcia?
Aby dokładniej przeanalizować proces obsługi faktur zobowiązań, wybierz instrukcję ekstrakcji danych dla konkretnego systemu lub skorzystaj z tego uniwersalnego szablonu jako punktu wyjścia.
Usprawnij obsługę zobowiązań już dziś
Usprawnij workflow, obniż koszty i zyskaj pełny obraz procesu obsługi zobowiązań.
Nie trzeba podawać danych karty płatniczej. Rozpoczęcie zajmuje tylko kilka minut.