Szablon danych do procesu fakturowania i wystawiania faktur, od zamówienia do płatności
Szablon danych do procesu fakturowania i wystawiania faktur, od zamówienia do płatności
To ogólny szablon danych do process mining dla procesu Od zamówienia do płatności: fakturowanie i wystawianie faktur. Aby uzyskać dokładniejsze wskazówki, skorzystaj z szablonów dla konkretnych systemów.
Wybierz konkretny system- Uniwersalny punkt wyjścia dla każdego systemu.
- Polecane atrybuty do szczegółowej analizy.
- Najważniejsze czynności do mapowania przebiegu fakturowania i wystawiania faktur.
Atrybuty procesu fakturowania i wystawiania faktur, od zamówienia do płatności
| Nazwa | Opis | ||
|---|---|---|---|
| Czas zdarzenia EventTime | Dokładny znacznik czasu wskazujący, kiedy miało miejsce określone działanie lub zdarzenie. | ||
| Opis Czas zdarzenia, czyli znacznik czasu, określa dokładną datę i godzinę wykonania działania lub zmiany statusu. Te dane pozwalają ustalić, kiedy odbywały się poszczególne etapy procesu i ile trwały. W analizie czas zdarzenia służy do chronologicznego uporządkowania działań oraz obliczania czasu między krokami, czasu trwania działań i całkowitego czasu realizacji każdej sprawy. Na tej podstawie można wykrywać wąskie gardła, mierzyć wyniki względem umów o poziomie usług i analizować zmiany w czasie. Bez dokładnych znaczników czasu analiza wyników i czasu trwania procesu nie jest możliwa. Dlaczego to ważne Ten znacznik czasu jest niezbędny do obliczania wskaźników opartych na czasie, takich jak czas realizacji i czas trwania, które pomagają wykrywać wąskie gardła. Skąd pobrać Zwykle znajduje się obok pól działania lub statusu w dziennikach transakcji, dokumentach zmian albo tabelach nagłówków i pozycji dokumentów. Przykłady 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:05Z | |||
| Identyfikator faktury InvoiceId | Unikalny identyfikator każdej faktury wystawionej klientowi. Jest to główny identyfikator sprawy w procesie rozliczania i fakturowania. | ||
| Opis Identyfikator faktury to unikalny kod alfanumeryczny przypisany do każdej wystawionej faktury. Łączy wszystkie powiązane działania, od utworzenia i zatwierdzenia po płatność i zamknięcie, w jedną instancję procesu, czyli sprawę. W analizie process mining identyfikator faktury jest niezbędny do odtworzenia całego przebiegu każdej faktury. Pozwala wizualizować przepływy procesu, wykrywać różnice i obliczać wskaźniki dla poszczególnych spraw, takie jak czas realizacji. Filtrowanie według identyfikatora faktury ułatwia też szczegółową analizę problematycznych spraw i ustalenie przyczyn opóźnień lub błędów. Dlaczego to ważne To unikalny identyfikator, który pozwala śledzić cały cykl życia faktury i stanowi podstawę analizy procesu rozliczania. Skąd pobrać Zwykle znajduje się w tabeli nagłówkowej dokumentów rozliczeniowych lub faktur w źródłowym systemie ERP albo finansowym. Przykłady INV-2023-00123910004587SI-58832 | |||
| Nazwa działania ActivityName | Nazwa działania biznesowego lub zdarzenia, które miało miejsce na określonym etapie cyklu życia faktury. | ||
| Opis Nazwa działania opisuje konkretny krok lub zadanie w procesie rozliczania, na przykład „Wystawiono fakturę”, „Wysłano fakturę do klienta” lub „Przypisano płatność do faktury”. Każde zdarzenie w dzienniku procesu jest powiązane z działaniem. Ich kolejność tworzy przepływ procesu. Analiza kolejności działań stanowi podstawę process mining. Pokazuje rzeczywiste ścieżki faktur, standardowe procedury, odstępstwa, pętle poprawek i wąskie gardła. Wiedza o tym, jakie działania występują, w jakiej kolejności i jak często, jest niezbędna do odkrywania procesów, sprawdzania zgodności i wskazywania możliwości usprawnień. Dlaczego to ważne Określa kroki procesu i umożliwia wizualizację oraz analizę przebiegu faktury od utworzenia do zamknięcia. Skąd pobrać Nazwę można zwykle ustalić na podstawie zmian statusu dokumentu, kodów transakcji lub dzienników zdarzeń w systemie źródłowym. Przykłady Zatwierdzenie fakturyOtrzymano płatnośćZgłoszono spórFaktura wysłana do klienta | |||
| Ostatnia aktualizacja danych LastDataUpdate | Znacznik czasu wskazujący, kiedy dane dotyczące tego zdarzenia zostały ostatnio odświeżone lub pobrane z systemu źródłowego. | ||
| Opis Ten atrybut zapisuje datę i godzinę ostatniego pobrania lub odświeżenia danych. Informuje o ich aktualności. W każdym projekcie process mining wiedza o aktualności danych jest ważna przy raportowaniu i analizie. Atrybut ten pozwala ustalić, jaki okres obejmuje analiza, i upewnić się, że decyzje opierają się na aktualnych informacjach. Pomaga też monitorować przepływy danych i sprawdzać, czy ich pobieranie przebiega zgodnie z planem. Dlaczego to ważne Informuje o aktualności danych, dzięki czemu analiza i decyzje mogą opierać się na najnowszych dostępnych informacjach. Skąd pobrać Ten znacznik czasu jest zwykle generowany i dodawany do zbioru danych podczas procesu ekstrakcji, transformacji i ładowania danych (ETL). Przykłady 2024-03-10T02:00:00Z2024-03-09T02:00:00Z2024-03-08T02:00:00Z | |||
| System źródłowy SourceSystem | System, z którego pobrano dane. | ||
| Opis Ten atrybut wskazuje aplikację biznesową lub system, w którym powstały dane o zdarzeniu, na przykład ERP, CRM lub własną platformę rozliczeniową. W środowisku z wieloma zintegrowanymi systemami pozwala rozróżnić źródła danych. Znajomość systemu źródłowego pomaga weryfikować dane, zarządzać nimi i rozwiązywać problemy. Gdy łączone są dane z kilku systemów, ten atrybut dostarcza kontekstu i pomaga wyjaśnić różnice w szczegółowości danych lub nazewnictwie. Ułatwia też dokładniejszą analizę różnic w procesie wynikających z użycia różnych systemów. Dlaczego to ważne Informacja o pochodzeniu danych jest ważna przy ich weryfikacji i analizie procesów obejmujących wiele systemów. Skąd pobrać Informacja ta może być zapisana w polu tabeli źródłowej lub dodana podczas procesu ekstrakcji, transformacji i ładowania danych (ETL). Przykłady SAP S/4HANAOracle NetSuiteSalesforceMicrosoft Dynamics 365 | |||
| Kwota faktury InvoiceAmount | Łączna wartość faktury, obejmująca wszystkie pozycje, podatki i opłaty. | ||
| Opis Kwota faktury to łączna wartość, którą klient powinien zapłacić. Jest to ważny wskaźnik finansowy przypisany do każdej sprawy dotyczącej faktury. Ten atrybut stanowi podstawę analizy finansowej w process mining. Pozwala podzielić faktury na kategorie według wartości, na przykład wysokiej i niskiej, a następnie sprawdzić, czy przebiegają różnymi ścieżkami lub mają różny czas realizacji. Służy też do obliczania wskaźników, takich jak DSO, i analizy finansowych skutków nieefektywności procesu, na przykład opóźnień w ściąganiu płatności za faktury o wysokiej wartości. Dlaczego to ważne Pozwala analizować skutki finansowe, ustalać priorytety problemów według ich wartości pieniężnej i sprawdzać, jak kwota faktury wpływa na przebieg procesu. Skąd pobrać Zwykle znajduje się w nagłówku faktury lub dokumentu rozliczeniowego w źródłowym systemie finansowym. Przykłady 5000.001250.7525000.5099.99 | |||
| Nazwa klienta CustomerName | Nazwa klienta lub podmiotu, na który wystawiono fakturę. | ||
| Opis Ten atrybut zawiera nazwę prawną lub handlową klienta, na którego wystawiono fakturę. Ułatwia identyfikację partnera biznesowego uczestniczącego w transakcji. Analiza procesu według nazwy klienta pomaga ustalić, czy określeni klienci częściej wiążą się z odstępstwami od procesu, opóźnieniami płatności lub sporami. Wnioski mogą pomóc w zarządzaniu relacjami z klientami i dostosowaniu komunikacji lub procesu do konkretnych kont. Umożliwiają też porównywanie wyników różnych grup klientów. Dlaczego to ważne Umożliwia analizę z perspektywy klienta i pomaga wykrywać wzorce, opóźnienia lub problemy dotyczące konkretnych klientów albo grup klientów. Skąd pobrać Dane pochodzą z danych podstawowych klientów i są powiązane z dokumentem faktury za pomocą identyfikatora klienta. Przykłady Global Trade CorpInnovate Solutions Ltd.Standard Manufacturing Co.Tech Services Inc. | |||
| Status faktury InvoiceStatus | Bieżący status faktury w jej cyklu życia, na przykład otwarta, opłacona lub zakwestionowana. | ||
| Opis Status faktury określa jej bieżący etap w całym procesie. Pokazuje, na jakim etapie znajduje się faktura, na przykład czy oczekuje na zatwierdzenie lub płatność, została opłacona w całości czy anulowana. Atrybut ten pomaga uzyskać ogólny obraz bieżącego obciążenia i sytuacji finansowej. Dashboardy często wykorzystują go do przedstawiania liczby i wartości faktur według statusu, na przykład łącznej wartości faktur otwartych lub przeterminowanych. W process mining analiza zmian statusu daje uproszczony, ogólny obraz przepływu procesu. Dlaczego to ważne Pozwala szybko sprawdzić, na jakim etapie procesu jest faktura. Przydaje się w dashboardach operacyjnych i do ogólnego monitorowania statusów. Skąd pobrać To standardowe pole w nagłówku większości tabel faktur lub dokumentów rozliczeniowych. Przykłady OtwartaOpłaconaPrzeterminowanaZakwestionowanaAnulowana | |||
| Termin płatności PaymentDueDate | Data, do której klient powinien zapłacić fakturę. | ||
| Opis Termin płatności to ważna data obliczana na podstawie daty faktury i uzgodnionych warunków płatności. Wyznacza granicę, po której faktura staje się przeterminowana. Ten atrybut jest niezbędny do monitorowania windykacji i zarządzania przepływami pieniężnymi. Służy do obliczania wskaźników, takich jak DSO i odsetek płatności dokonanych w terminie. Porównanie faktycznej daty płatności z terminem pozwala wykrywać opóźnienia, analizować zachowania płatnicze różnych klientów i oceniać skuteczność windykacji. Dlaczego to ważne Ta data stanowi punkt odniesienia przy ocenie terminowości płatności, obliczaniu DSO i wykrywaniu przeterminowanych faktur, które bezpośrednio wpływają na przepływy pieniężne. Skąd pobrać Znajduje się w danych nagłówka faktury. Można ją wprowadzić bezpośrednio lub obliczyć na podstawie daty faktury i warunków płatności. Przykłady 2023-11-302024-01-152024-02-28 | |||
| Użytkownik User | Identyfikator użytkownika, pracownika lub systemu odpowiedzialnego za wykonanie określonego działania. | ||
| Opis Ten atrybut wskazuje osobę lub agenta systemowego, który wykonał dane zadanie w procesie. Może to być osoba, która utworzyła fakturę, zatwierdziła ją lub przypisała do niej płatność. Analiza działań według użytkownika pomaga zrozumieć rozkład obciążenia, indywidualne wyniki i potrzeby szkoleniowe. Może wskazać użytkowników lub zespoły pracujące sprawnie oraz tych, którzy potrzebują dodatkowego wsparcia. Informacja ta jest też niezbędna do zapewnienia zgodności i przeprowadzania audytów, ponieważ pozwala ustalić, kto wykonał ważne działania w procesie. Dlaczego to ważne Pozwala analizować wyniki i obciążenie zasobów, oceniać sprawność zespołów oraz wskazywać potrzeby szkoleniowe. Skąd pobrać Zwykle znajduje się w dziennikach zmian lub tabelach historii dokumentu i jest powiązany z każdym zarejestrowanym zdarzeniem lub transakcją. Przykłady j.doeAccountingBotm.smithe.jones | |||
| Waluta Currency | Kod waluty, w której podano kwoty na fakturze, na przykład USD lub EUR. | ||
| Opis Atrybut „Waluta” określa jednostkę pieniężną dla kwoty faktury. Jest niezbędny do prawidłowej interpretacji wartości finansowych, zwłaszcza w organizacjach działających na rynkach międzynarodowych i używających wielu walut. W analizie pole „Waluta” pozwala prawidłowo sumować i porównywać dane finansowe. Przed obliczeniem łącznych wartości lub porównaniem kwot faktur z różnych regionów należy przeliczyć je na wspólną walutę. Atrybut ten jest niezbędny do rzetelnego raportowania finansowego i analizy wyników procesu według waluty lub regionu. Dlaczego to ważne Dostarcza kontekstu niezbędnego do prawidłowej analizy i raportowania wartości finansowych, szczególnie w organizacjach działających w wielu krajach. Skąd pobrać Znajduje się w nagłówku faktury lub dokumentu rozliczeniowego, zwykle obok pól z kwotami. Przykłady USDEURGBPJPY | |||
| Czy ponowiono pracę IsRework | Flaga wskazująca, czy w procesie fakturowania ponawiano pracę, na przykład poprawiano dane lub przeprowadzano kilka cykli akceptacji. | ||
| Opis IsRework to flaga logiczna, która przyjmuje wartość true, jeśli faktura przeszła przez co najmniej jedną pętlę ponownej pracy. Obejmuje to czynności związane z poprawianiem błędów lub powtarzaniem kroku, który powinien być wykonany tylko raz, na przykład ponowne przesłanie do akceptacji odrzuconej faktury. Ten atrybut bezpośrednio mierzy nieefektywność procesu. Po odfiltrowaniu przypadków, w których IsRework ma wartość true, analitycy mogą szybko znaleźć problematyczne faktury i zbadać przyczyny ponownej pracy. Wskaźnik ponownej pracy, czyli odsetek przypadków, w których ją ponawiano, to KPI pozwalający ocenić jakość procesu i wskazać możliwości usprawnienia operacji oraz ograniczenia zbędnego nakładu pracy. Dlaczego to ważne Bezpośrednio wskazuje nieefektywność procesu, ułatwiając znalezienie i analizę przypadków wymagających dodatkowej pracy, która nie przynosi wartości. Skąd pobrać Tego atrybutu zwykle nie ma w systemach źródłowych. Trzeba go wyliczyć podczas transformacji danych, wykrywając sekwencje czynności wskazujące na ponowne wykonanie pracy. Przykłady truefalse | |||
| Jednostka organizacyjna OrganizationalUnit | Jednostka biznesowa, kod spółki lub organizacja sprzedaży odpowiedzialna za fakturę. | ||
| Opis Ten atrybut wskazuje konkretną jednostkę wewnątrz firmy, która wystawiła fakturę lub odpowiada za transakcję. Może to być kod spółki, jednostka biznesowa albo organizacja sprzedaży. Analiza procesu według jednostek organizacyjnych pozwala porównywać wyniki różnych części firmy. Ułatwia ustalenie, które jednostki działają najsprawniej, gdzie najczęściej trzeba ponawiać pracę i które mają największe problemy z opóźnionymi płatnościami. Dzięki temu można rozliczać jednostki z wyników i ujednolicać procesy w całej organizacji. Dlaczego to ważne Umożliwia porównanie wyników różnych jednostek biznesowych oraz wskazanie dobrych praktyk i obszarów wymagających poprawy. Skąd pobrać To podstawowe pole danych organizacyjnych, które znajduje się w nagłówku niemal każdego dokumentu finansowego w systemie ERP. Przykłady 1000US01Usługi globalneProdukcja w UE | |||
| Numer zamówienia sprzedaży SalesOrderNumber | Identyfikator zamówienia sprzedaży, na podstawie którego wystawiono fakturę. | ||
| Opis Numer zamówienia sprzedaży wskazuje wcześniejszy dokument w łańcuchu Order-to-Cash, który zapoczątkował wystawienie faktury. Łączy proces rozliczania ze sprzedażą. Ten atrybut pozwala analizować cały proces Order-to-Cash. Powiązanie faktur z zamówieniami sprzedaży umożliwia prześledzenie pełnego cyklu, od zamówienia klienta po otrzymanie płatności. Dzięki temu można sprawdzić, jak problemy ze sprzedażą lub realizacją zamówienia wpływają na rozliczenia i windykację. Dlaczego to ważne Łączy proces rozliczania z wcześniejszym etapem sprzedaży i umożliwia analizę całego procesu Order-to-Cash. Skąd pobrać To odwołanie jest zwykle zapisane w nagłówku faktury lub jej pozycjach i łączy ją z tabelą dokumentów sprzedaży. Przykłady SO-10582490000123ORD-2023-987 | |||
| Region klienta CustomerRegion | Region geograficzny, terytorium lub kraj powiązany z klientem. | ||
| Opis Region klienta określa jego położenie geograficzne. Może być zdefiniowany na różnych poziomach, na przykład jako kraj, stan lub własny region sprzedaży. Ten atrybut ułatwia segmentację. Analiza procesu fakturowania według regionów może ujawnić różnice w wynikach, takie jak czas płatności, odsetek sporów czy zgodność z procedurami. Na tej podstawie można dostosować działania windykacyjne i obsługę klienta do poszczególnych regionów. Można też wskazać dobre praktyki stosowane w regionach osiągających lepsze wyniki i wykorzystać je w innych obszarach. Dlaczego to ważne Umożliwia analizę geograficzną i pokazuje regionalne różnice w zachowaniach płatniczych, efektywności procesu i zgodności. Skąd pobrać Pochodzi z podstawowych danych klienta, zwykle z jego adresu. Przykłady Ameryka PółnocnaEMEANiemcyAzja i Pacyfik | |||
| Warunki płatności PaymentTerms | Uzgodnione zasady płatności za fakturę, na przykład płatność w ciągu 30 dni lub w dniu otrzymania. | ||
| Opis Warunki płatności określają zasady uzgodnione przez sprzedawcę i nabywcę. Obejmują termin płatności oraz ewentualne rabaty za wcześniejszą zapłatę. Analiza procesu według warunków płatności może pokazać, czy określone warunki wiążą się z dłuższym czasem oczekiwania na płatność lub częstszymi opóźnieniami. Te informacje pomagają dostosować warunki płatności, aby poprawić przepływy pieniężne. Są też przydatne przy ustalaniu, dlaczego niektóre faktury stają się przeterminowane. Dlaczego to ważne Ten atrybut wpływa na termin płatności i zachowania płatnicze klientów, dlatego pomaga zrozumieć i poprawić terminowość płatności. Skąd pobrać Zwykle jest zapisany zarówno w danych podstawowych klienta, jak i w nagłówku konkretnej faktury. Przykłady Płatność w ciągu 30 dniPłatność w ciągu 60 dniPłatność w dniu otrzymania2% rabatu przy płatności w ciągu 10 dni, w przeciwnym razie płatność w ciągu 30 dni | |||
Czynności w procesie fakturowania i wystawiania faktur, od zamówienia do płatności
| Działanie | Opis | ||
|---|---|---|---|
| Faktura wysłana do klienta | Zatwierdzona faktura została oficjalnie dostarczona klientowi wybranym kanałem, na przykład e-mailem, pocztą lub przez portal internetowy. Od tego momentu zaczyna biec termin płatności. | ||
| Dlaczego to ważne To zdarzenie rozpoczyna cykl windykacji i ma zasadnicze znaczenie przy obliczaniu wskaźnika DSO (liczby dni sprzedaży należności) oraz odsetka płatności dokonanych w terminie. Skąd pobrać Informacje o tym zdarzeniu znajdują się w dziennikach zarządzania wydrukami, rejestrach komunikacji lub w polu „Data wysłania” na fakturze. Rejestrowanie Użyj znacznika czasu z dzienników systemowych, które rejestrują wysłanie faktury e-mailem, wydrukowanie jej lub przesłanie przez EDI. Typ zdarzenia explicit | |||
| Otrzymano płatność od klienta | Płatność od klienta wpłynęła i została zarejestrowana w systemie finansowym. Na tym etapie wpływ środków jest odnotowany, ale płatność może nie być jeszcze przypisana do konkretnej faktury. | ||
| Dlaczego to ważne To ważne zdarzenie z punktu widzenia przepływów pieniężnych. Czas między otrzymaniem płatności a jej przypisaniem do faktury pozwala ocenić sprawność rozliczania wpłat. Skąd pobrać Zdarzenie jest rejestrowane w dziennikach wpływów gotówkowych, tabelach transakcji płatniczych lub tabelach przetwarzania wyciągów bankowych. Rejestrowanie Wykryj utworzenie rekordu płatności od klienta lub wpływu gotówkowego. Typ zdarzenia explicit | |||
| Płatność przypisana do faktury | Otrzymana płatność została dopasowana do konkretnej faktury i do niej przypisana. To uzgodnienie zmniejsza lub zeruje saldo należności z faktury. | ||
| Dlaczego to ważne To zdarzenie pozwala mierzyć czas rozliczania wpłat. Opóźnienia mogą zniekształcać obraz wieku należności i utrudniać zarządzanie kredytem kupieckim. Skąd pobrać Informacje znajdują się w księgach pomocniczych należności, w tabelach łączących dokumenty płatności z fakturami. Takie dokumenty często nazywa się dokumentami rozliczeniowymi. Rejestrowanie Zapisz znacznik czasu powiązania rekordu płatności z rekordem faktury w celu rozliczenia otwartej pozycji. Typ zdarzenia explicit | |||
| Upłynął termin płatności faktury | To zdarzenie obliczane, które następuje po upływie terminu płatności faktury. Nie jest czynnością transakcyjną, lecz punktem w czasie wyznaczonym na podstawie daty wystawienia faktury i warunków płatności. | ||
| Dlaczego to ważne Ten moment pozwala oznaczyć faktury jako przeterminowane i analizować terminowość płatności. Może też uruchamiać działania windykacyjne. Skąd pobrać Zdarzenie nie jest rejestrowane bezpośrednio. Oblicza się je na podstawie daty faktury i warunków płatności. Rejestrowanie Oblicz jako „Data wysłania faktury” + „Liczba dni na płatność”. Typ zdarzenia calculated | |||
| Wystawienie faktury | To działanie oznacza utworzenie rekordu faktury w systemie. Rozpoczyna proces fakturowania. Zwykle jest wyzwalane automatycznie po realizacji zamówienia sprzedaży lub wykonywane ręcznie. | ||
| Dlaczego to ważne Jako punkt początkowy zdarzenie to ma znaczenie przy obliczaniu czasu obsługi faktury od początku do końca i wykrywaniu opóźnień na wczesnym etapie procesu. Skąd pobrać Dane pochodzą ze znacznika czasu utworzenia rekordu w głównej tabeli faktur lub dokumentów rozliczeniowych. Rejestrowanie Znajdź zdarzenie utworzenia faktury lub znacznik czasu jej pierwszego zapisania w systemie. Typ zdarzenia explicit | |||
| Zamknięto fakturę | Faktura zostaje oficjalnie zamknięta, co oznacza zakończenie jej cyklu życia. Następuje to, gdy saldo należności spadnie do zera w wyniku płatności, not kredytowych lub innych korekt. | ||
| Dlaczego to ważne To główny pomyślny koniec procesu. Zdarzenie pozwala obliczyć całkowity czas jego trwania i odsetek spraw zakończonych. Skąd pobrać Status często jest wywnioskowany z wyzerowania salda faktury albo wynika z jawnej zmiany statusu w systemie. Rejestrowanie Ustal najpóźniejszy znacznik czasu transakcji, na przykład przypisania płatności, która wyzerowała saldo faktury. Typ zdarzenia inferred | |||
| Anulowano fakturę | Istniejąca faktura zostaje unieważniona lub anulowana, co odwraca jej wpływ finansowy. Zwykle dzieje się tak, aby poprawić poważny błąd przed otrzymaniem płatności, na przykład gdy fakturę wystawiono na niewłaściwego klienta. | ||
| Dlaczego to ważne Anulowanie wskazuje na błędy operacyjne wymagające ponownej pracy i może opóźnić prawidłowe rozliczenie. Częste anulowanie faktur może świadczyć o problemach z procesem lub jakością danych. Skąd pobrać Zdarzenie można wykryć na podstawie dokumentów storna lub statusu „anulowana” albo „unieważniona” w rekordzie faktury. Rejestrowanie Sprawdź, czy utworzono dokument storna powiązany z pierwotną fakturą albo czy status zmienił się na „Unieważniona”. Typ zdarzenia explicit | |||
| Faktura skorygowana | Faktura została zmieniona po utworzeniu, często z powodu odrzucenia lub wykrycia błędu. Zmiana może dotyczyć kwot, pozycji na fakturze lub danych klienta. | ||
| Dlaczego to ważne Częste korekty mogą wskazywać na problemy z danymi podstawowymi lub realizacją zamówienia. Prowadzą do ponownej pracy i opóźnień. Skąd pobrać Zdarzenie można wywnioskować z dzienników zmian i ścieżek audytu albo rozpoznać po schemacie, w którym faktura jest anulowana, a następnie ponownie wystawiana dla tego samego zamówienia. Rejestrowanie Wykryj zmiany kluczowych pól finansowych w danych faktury po jej utworzeniu. Typ zdarzenia inferred | |||
| Odpisano należność z faktury | Pozostałe saldo faktury zostaje anulowane i zaklasyfikowane jako nieściągalna należność. Zwykle następuje to po wyczerpaniu wszystkich możliwości windykacji. | ||
| Dlaczego to ważne Oznacza to niepowodzenie windykacji i bezpośrednią stratę finansową. Analiza odpisów pomaga wskazać klientów wysokiego ryzyka i usprawnić politykę kredytową. Skąd pobrać Zdarzenie jest rejestrowane jako korekta lub zapis księgowy, który rozlicza saldo faktury na koncie nieściągalnych należności. Rejestrowanie Wykryj transakcje korygujące saldo faktury z kodem przyczyny „odpis” lub księgowane na koncie nieściągalnych należności. Typ zdarzenia explicit | |||
| Odrzucenie faktury | Osoba zatwierdzająca odrzuciła fakturę podczas wewnętrznej weryfikacji. Zwykle trzeba ją poprawić i ponownie przekazać do zatwierdzenia, co tworzy pętlę poprawek. | ||
| Dlaczego to ważne To działanie wskazuje na nieefektywność procesu wewnętrznego, problemy z jakością danych i poprawki, które wydłużają obsługę faktury oraz opóźniają płatność. Skąd pobrać Zdarzenie jest zwykle rejestrowane jako zmiana statusu rekordu faktury, często wraz z komentarzem o przyczynie odrzucenia w powiązanych tabelach. Rejestrowanie Zapisz zdarzenie zmiany statusu faktury na „Odrzucona” lub podobny. Typ zdarzenia explicit | |||
| Przekazanie faktury do zatwierdzenia | Oznacza przekazanie wystawionej faktury do formalnego wewnętrznego workflow weryfikacji. Ten etap występuje często w organizacjach, w których przed zatwierdzeniem faktury wymagany jest przegląd kierowniczy. | ||
| Dlaczego to ważne Śledzenie przekazania faktur do zatwierdzenia i samych akceptacji pomaga wykryć wąskie gardła w procesach wewnętrznych, które opóźniają wysyłkę faktur do klientów i wpływają na przepływy pieniężne. Skąd pobrać Zdarzenie jest zwykle rejestrowane jako zmiana statusu lub wpis w dzienniku systemu zarządzania workflow. Rejestrowanie Zapisz znacznik czasu zmiany statusu faktury na „Oczekuje na zatwierdzenie” lub podobny. Typ zdarzenia explicit | |||
| Wysłano przypomnienie o płatności | Do klienta wysłano wiadomość dotyczącą przeterminowanej faktury, na przykład wezwanie do zapłaty lub e-mail. To ważny etap windykacji, który ma skłonić klienta do zapłaty. | ||
| Dlaczego to ważne Śledzenie przypomnień pozwala ocenić skuteczność windykacji i wskazać klientów, których trzeba często ponaglać. Skąd pobrać Dane można pobrać z dzienników przebiegów windykacyjnych, systemów windykacji lub dzienników komunikacji powiązanych z klientem albo fakturą. Rejestrowanie Użyj znacznika czasu z tabeli historii windykacji lub dziennika działań windykacyjnych. Typ zdarzenia explicit | |||
| Wystawiono notę kredytową | Utworzono notę kredytową, często przypisywaną do istniejącej faktury. Zwykle służy do poprawienia błędu w rozliczeniu, przyznania obniżki ceny lub rozliczenia zwróconych towarów. | ||
| Dlaczego to ważne Częste wystawianie not kredytowych może wskazywać na problemy ze sprzedażą lub realizacją zamówień, które prowadzą do utraty przychodów albo niezadowolenia klientów. Skąd pobrać Zdarzenie można wykryć na podstawie utworzenia dokumentu noty kredytowej, który często jest powiązany z pierwotną fakturą. Rejestrowanie Zapisz znacznik czasu utworzenia transakcji typu nota kredytowa. Typ zdarzenia explicit | |||
| Zatwierdzenie faktury | Faktura pomyślnie przeszła wszystkie wewnętrzne kontrole i została formalnie zatwierdzona. Oznacza to, że uznano ją za prawidłową i można ją wysłać do klienta. | ||
| Dlaczego to ważne To ważny punkt procesu, który oddziela czas obsługi wewnętrznej od czasu, jaki klient ma na zapłatę. Analiza czasu do zatwierdzenia pokazuje sprawność procesu wewnętrznego. Skąd pobrać Dane pochodzą z dziennika systemu workflow lub ze zmiany statusu dokumentu faktury z „Oczekuje” na „Zatwierdzona”. Rejestrowanie Zapisz znacznik czasu ostatniego zatwierdzenia w dzienniku workflow lub przy zmianie statusu. Typ zdarzenia explicit | |||
| Zgłoszono spór | Klient formalnie zakwestionował całość lub część faktury, na przykład z powodu nieprawidłowej ceny lub ilości. Zwykle wstrzymuje to windykację do czasu rozstrzygnięcia sporu. | ||
| Dlaczego to ważne Analiza sporów pomaga ustalić przyczyny niezadowolenia klientów i błędów w rozliczeniach, które bezpośrednio wpływają na DSO i relacje z klientami. Skąd pobrać Zdarzenie jest zwykle rejestrowane jako zmiana statusu, flaga na fakturze lub utworzenie osobnej sprawy sporu powiązanej z fakturą. Rejestrowanie Zapisz datę utworzenia sprawy sporu lub zmianę statusu na „Zakwestionowana”. 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?
Przejdźcie do analizy procesu, wybierając instrukcję ekstrakcji dla konkretnego systemu. Można też zacząć od uniwersalnego szablonu i dostosować go do własnych danych.
Usprawnij fakturowanie i popraw przepływy pieniężne
Wykryj wąskie gardła, ogranicz błędy i przyspiesz płatności.
Nie trzeba podawać danych karty płatniczej. Można zacząć w kilka minut.