Szablon danych dotyczących zarządzania kredytami i windykacji
Szablon danych dotyczących zarządzania kredytami i windykacji
- Zalecane atrybuty do zebrania
- Najważniejsze działania do śledzenia
- Wskazówki dotyczące ekstrakcji danych z SAP ECC
Atrybuty procesu zarządzania kredytami i windykacji
| Nazwa | Opis | ||
|---|---|---|---|
|
Czas zdarzenia
EventTime
|
Znacznik czasu określający, kiedy wystąpiło dane działanie lub zdarzenie. | ||
|
Opis
Czas zdarzenia zapisuje dokładną datę i godzinę każdego działania w procesie. Stanowi chronologiczną podstawę dziennika zdarzeń, pozwala uporządkować działania i obliczyć czas między nimi. Ten znacznik czasu jest niezbędny do obliczania wszystkich czasowych KPI, takich jak czas rozpatrywania sporu, opóźnienie księgowania płatności czy średnia liczba dni od terminu płatności do zapłaty. Pomaga wykrywać wąskie gardła, wskazując długie przerwy między kolejnymi krokami.
Dlaczego to ważne
Ten atrybut jest niezbędny do prawidłowego uporządkowania zdarzeń i obliczania wskaźników związanych z czasem, takich jak czas cyklu i czas trwania działań.
Skąd pobrać
Dane pochodzą z różnych pól daty i czasu w tabelach SAP, takich jak BUDAT (data księgowania) lub CPUDT/CPUTM (data i godzina wprowadzenia dokumentu) w BKPF, a także z tabel dotyczących konkretnych zdarzeń.
Przykłady
2023-01-15T09:30:00Z2023-02-10T14:00:00Z2023-02-28T11:25:10Z
|
|||
|
Nazwa działania
ActivityName
|
Nazwa działania biznesowego lub zdarzenia, które wystąpiło na określonym etapie cyklu życia faktury. | ||
|
Opis
Ten atrybut opisuje konkretny krok lub zdarzenie w procesie zarządzania należnościami i windykacji, na przykład „Zaksięgowanie faktury”, „Wykonanie przebiegu przypominania o płatności” lub „Zaksięgowanie dokumentu płatności przychodzącej”. Działania te tworzą węzły mapy procesu. Analiza kolejności, częstotliwości i czasu między działaniami pozwala zobrazować rzeczywisty przebieg procesu, wykryć odstępstwa od standardowych procedur i wskazać wąskie gardła. Na przykład analiza ścieżki po zdarzeniu „Wykonanie przebiegu przypominania o płatności” może pokazać skuteczność przyjętej strategii.
Dlaczego to ważne
Działania są podstawowymi elementami mapy procesu. Umożliwiają wizualizację i analizę przebiegu procesu, jego wariantów oraz wyjątków.
Skąd pobrać
To atrybut pochodny, zwykle tworzony przez przypisanie kodów transakcji (TCODE), typów dokumentów (BLART) lub zmian określonych pól w różnych tabelach SAP, np. BKPF, BSID, MHNK i UDM_CASE, do czytelnych nazw działań.
Przykłady
Zaksięgowanie fakturyWykonanie przebiegu przypominania o płatnościZarejestrowanie obietnicy zapłatyZaksięgowanie dokumentu płatności przychodzącejRozliczenie faktury
|
|||
|
Numer faktury
InvoiceNumber
|
Unikalny identyfikator faktury klienta, który służy jako główny identyfikator sprawy w procesie zarządzania należnościami. | ||
|
Opis
Numer faktury, w SAP określany jako Belegnummer (BELNR), jednoznacznie identyfikuje każdy dokument należności. W process mining jest niezbędny, ponieważ łączy wszystkie powiązane działania, od księgowania i przypominania o płatności po zapłatę lub odpis, w jedną sprawę. Analiza procesu z numerem faktury jako identyfikatorem sprawy daje pełny obraz cyklu życia faktury. Ułatwia śledzenie wskaźników, takich jak DSO, wykrywanie wąskich gardeł w windykacji i ocenę skuteczności różnych strategii dla poszczególnych faktur.
Dlaczego to ważne
To podstawowy identyfikator łączący wszystkie zdarzenia w cyklu życia faktury. Umożliwia prześledzenie i analizę całego procesu od udzielenia kredytu do otrzymania płatności.
Skąd pobrać
Pole BELNR występuje w różnych tabelach księgowości finansowej SAP ECC, przede wszystkim w BKPF (nagłówek dokumentu księgowego) i BSEG (pozycja dokumentu księgowego).
Przykłady
190000000119000000451900000102
|
|||
|
Kwota faktury
Dmbtr
|
Łączna wartość faktury w walucie lokalnej. | ||
|
Opis
Ten atrybut określa łączną wartość faktury. W SAP kwota w walucie lokalnej jest często zapisywana w polu DMBTR. Kwota faktury to ważny wymiar analizy. Pozwala ustalać priorytety windykacji faktur o wysokiej wartości oraz sprawdzać, czy kwota wiąże się z opóźnieniami płatności lub sporami. Można filtrować mapę procesu, aby uwzględnić tylko faktury przekraczające określony próg.
Dlaczego to ważne
Dostarcza kontekstu finansowego, umożliwia analizę według wartości i ustalanie priorytetów windykacji faktur o wysokiej wartości.
Skąd pobrać
Standardowe pole DMBTR (kwota w walucie lokalnej) w tabelach takich jak BSEG, BSID i BSAD.
Przykłady
1500.0012500.50750.25
|
|||
|
Liczba dni po terminie
DaysOverdue
|
Obliczona liczba dni, o które faktura przekroczyła termin płatności. | ||
|
Opis
Wskaźnik oblicza liczbę dni między terminem płatności faktury a datą jej rozliczenia. W przypadku nierozliczonych faktur obliczenie opiera się na bieżącej dacie. Liczba dni po terminie to podstawowy wskaźnik w analizie należności. Jest główną miarą w dashboardzie „Przegląd zaległości na fakturach” i pomaga ustalać priorytety działań windykacyjnych. Analiza trendów dla całego portfela należności może pokazać jego ogólną kondycję.
Dlaczego to ważne
Podstawowy wskaźnik wyników, który mierzy opóźnienia w płatnościach. Pomaga ustalać priorytety działań windykacyjnych i oceniać kondycję procesu.
Skąd pobrać
Atrybut obliczany według wzoru: (data rozliczenia lub bieżąca data) − termin płatności netto.
Przykłady
0153295
|
|||
|
Nazwa użytkownika
UserName
|
Identyfikator użytkownika, który wykonał dane działanie. | ||
|
Opis
Ten atrybut wskazuje użytkownika odpowiedzialnego za dane zdarzenie, na przykład zaksięgowanie faktury lub utworzenie sprawy sporu. W SAP informacja ta jest często zapisywana w polach takich jak ERNAM (utworzył) lub USNAM. Analiza według użytkownika pomaga ocenić rozkład obciążenia pracą, określić potrzeby szkoleniowe i wykryć potencjalne problemy ze zgodnością. Może na przykład ujawnić, czy określeni użytkownicy regularnie powodują odstępstwa lub opóźnienia albo czy osoby osiągające najlepsze wyniki stosują sprawniejszy wariant procesu.
Dlaczego to ważne
Umożliwia analizę pracy i zachowań ludzi w procesie, pomagając wskazać osoby osiągające najlepsze wyniki, potrzeby szkoleniowe i nierównomierny rozkład obciążenia.
Skąd pobrać
Zwykle znajduje się w tabelach nagłówków, takich jak BKPF, w polu USNAM (nazwa użytkownika) lub ERNAM (nazwa osoby, która utworzyła obiekt).
Przykłady
SMITHJRDOECFO-ADMIN
|
|||
|
Numer klienta
Kunnr
|
Unikalny identyfikator klienta. | ||
|
Opis
Numer klienta (KUNNR w SAP) to unikalny identyfikator konta klienta. Łączy transakcję z danymi podstawowymi konkretnego klienta, w tym historią płatności, informacjami kredytowymi i danymi kontaktowymi. W process mining ten atrybut jest niezbędny do segmentowania analizy. Pozwala porównywać przebieg procesu dla różnych klientów, wykrywać osoby regularnie spóźniające się z płatnościami i analizować różnice w strategiach windykacyjnych dla klientów strategicznych i pozostałych. Jest podstawą dashboardów, takich jak wiekowanie faktur i zgodność z warunkami płatności.
Dlaczego to ważne
Umożliwia analizę z perspektywy klienta, pomaga wykrywać wzorce zachowań poszczególnych klientów i grup oraz dostosowywać strategie windykacyjne.
Skąd pobrać
Standardowe pole KUNNR w tabelach pozycji klienta (BSID, BSAD) i tabelach nagłówków dokumentów (BKPF, jeśli zostało wypełnione).
Przykłady
10002050CUST-7890
|
|||
|
Osoba odpowiedzialna za windykację
Sachp
|
Pracownik księgowości lub windykator przypisany do konta klienta. | ||
|
Opis
Ten atrybut wskazuje osobę lub grupę odpowiedzialną za windykację należności od danego klienta. W SAP jest to często pracownik księgowości (SACHP) wskazany w rekordzie danych podstawowych klienta. Ten wymiar ma duże znaczenie przy ocenie pracy zespołu windykacji. Pozwala tworzyć dashboardy, takie jak „Przegląd zaległości na fakturach”, z filtrem według osoby odpowiedzialnej. Ułatwia to zarządzanie obciążeniem pracą i porównywanie skuteczności poszczególnych osób lub zespołów. Można sprawdzić, kto najskuteczniej doprowadza do uregulowania zaległych faktur.
Dlaczego to ważne
Umożliwia analizę wyników i zarządzanie obciążeniem zespołu windykacji przez przypisanie spraw i ich rezultatów do konkretnych osób lub grup.
Skąd pobrać
Zwykle znajduje się w danych spółki klienta (tabela KNB1, pole SACHP).
Przykłady
Jan KowalskiZespół AWIND-MIĘDZYNAR.
|
|||
|
Poziom monitowania
Mahns
|
Najwyższy poziom monitowania (przypomnień), jaki osiągnięto dla faktury. | ||
|
Opis
Poziom monitowania (MAHNS w SAP) wskazuje, ile przypomnień wysłano w sprawie zaległej faktury, a tym samym określa intensywność procedury monitowania. Ten atrybut służy do oceny procesu monitowania. Jest bezpośrednio wykorzystywany w dashboardzie „Skuteczność monitowania według poziomu”, który pokazuje, jaki odsetek faktur zostaje opłacony po wysłaniu każdego kolejnego przypomnienia. Analiza pomaga dostosować strategię monitowania, na przykład zmienić terminy lub treść przypomnień na poziomach, które nie przynoszą oczekiwanych rezultatów.
Dlaczego to ważne
Bezpośrednio mierzy intensywność działań windykacyjnych, co pozwala ocenić skuteczność strategii monitowania.
Skąd pobrać
Pole MAHNS w pozycji klienta w tabeli BSID. Historia monitów znajduje się w tabelach MHNK (nagłówek) i MHND (dane).
Przykłady
1234
|
|||
|
Segment klienta
CustomerSegment
|
Klasyfikacja klienta, na przykład według wielkości, branży lub znaczenia strategicznego. | ||
|
Opis
Segment klienta to klasyfikacja, która grupuje klientów o podobnych cechach. Często wynika z grupy kont klienta (KTOKD) w SAP lub innych pól niestandardowych w danych podstawowych klienta. Podział analizy procesu według tego atrybutu dostarcza przydatnych informacji. Może ujawnić, czy klienci z określonych segmentów dłużej regulują płatności, częściej zgłaszają spory lub lepiej reagują na konkretne działania windykacyjne. Informacje te pomagają usprawniać strategie windykacyjne i dostosowywać kontakt z klientami.
Dlaczego to ważne
Umożliwia analizę przebiegu procesu dla różnych typów klientów, co ułatwia dostosowanie strategii i przydział zasobów.
Skąd pobrać
Często określany na podstawie pola grupy kont klienta (KTOKD) w tabeli danych podstawowych KNA1 lub innych pól niestandardowych.
Przykłady
Klienci strategiczniMałe i średnie firmyAdministracja publicznaWewnętrzni
|
|||
|
Termin płatności
NetDueDate
|
Data, do której zgodnie z umową należy opłacić fakturę. | ||
|
Opis
Termin płatności to data, do której klient powinien zapłacić fakturę. Oblicza się go na podstawie daty bazowej faktury i warunków płatności. W SAP termin płatności netto jest często dostępny w polu FAEDT. Ta data stanowi podstawę zarządzania należnościami i pomiaru terminowości płatności. Służy do obliczania KPI, takich jak „Średnia liczba dni od terminu płatności do zapłaty”, oraz uruchamiania działań windykacyjnych po upływie terminu. Analiza opóźnień względem tej daty jest podstawowym elementem analizy windykacji.
Dlaczego to ważne
To podstawowy punkt odniesienia przy pomiarze terminowości płatności. Jest niezbędny do obliczania liczby dni opóźnienia i powiązanych KPI.
Skąd pobrać
Data ta jest często dostępna bezpośrednio w tabelach pozycji klienta, takich jak BSID, w polu FAEDT (termin płatności netto). Można ją też obliczyć na podstawie daty bazowej (ZFBDT) i warunków płatności (ZTERM).
Przykłady
2023-02-142023-03-312023-04-15
|
|||
|
Czy odpisano jako nieściągalną należność
IsWrittenOff
|
Wartość logiczna wskazująca, czy fakturę ostatecznie odpisano jako nieściągalną należność. | ||
|
Opis
To atrybut pochodny. Zwykle przyjmuje wartość true, jeśli fakturę rozliczono z użyciem określonego kodu przyczyny lub rodzaju dokumentu oznaczającego odpis. Wskazuje przypadki, które przyniosły stratę finansową. Atrybut ten jest niezbędny do obliczenia KPI „Wskaźnik odpisów nieściągalnych należności” i tworzenia powiązanych dashboardów. Umożliwia analizę przyczyn, dzięki której można ustalić, jakie cechy faktur i klientów najczęściej wiążą się z odpisami. Wyniki mogą pomóc ulepszyć politykę kredytową i skuteczność windykacji.
Dlaczego to ważne
Wskazuje wyniki procesu, które przynoszą straty finansowe. Umożliwia analizę przyczyn nieściągalnych należności i ulepszanie polityki kredytowej.
Skąd pobrać
Atrybut pochodny. Zwykle jest wyznaczany na podstawie określonych kodów przyczyn rozliczenia (BSEG-RSTGR) lub rodzajów dokumentów (BKPF-BLART) używanych przy odpisach.
Przykłady
truefalse
|
|||
|
Dokument rozliczający
Augbl
|
Numer dokumentu, którym rozliczono fakturę, zwykle dokumentu płatności lub noty kredytowej. | ||
|
Opis
Numer dokumentu rozliczającego (AUGBL w SAP) łączy pozycję otwartą, na przykład fakturę, z dokumentem, który ją rozliczył. Po opłaceniu faktury numer dokumentu płatności jest zapisywany jako dokument rozliczający tę fakturę. To pole jest niezbędne do potwierdzenia rozliczenia faktury i powiązania jej z konkretną płatnością lub notą kredytową. Stanowi podstawę do identyfikacji działania „Rozliczono fakturę” i prawidłowego odwzorowania całego procesu.
Dlaczego to ważne
Bezpośrednio łączy fakturę z dokumentem rozliczającym, co pozwala prawidłowo modelować zdarzenia rozliczenia.
Skąd pobrać
Standardowe pole AUGBL w tabelach pozycji klienta BSID (puste, gdy pozycja jest otwarta) i BSAD (wypełnione po rozliczeniu).
Przykłady
140000000114000000551400000120
|
|||
|
Identyfikator sprawy spornej
DisputeCaseId
|
Unikalny identyfikator sprawy spornej powiązanej z fakturą. | ||
|
Opis
Gdy klient kwestionuje fakturę, w module SAP Dispute Management można utworzyć formalną sprawę sporną. Jej identyfikatorem jest ten numer. Dzięki niemu można szczegółowo analizować proces rozpatrywania sporów. Jest niezbędny do obliczenia KPI „Czas rozpatrywania sporu” oraz ustalenia, dlaczego powstają spory, jak są obsługiwane i jakie są ich najczęstsze rozstrzygnięcia. Pozwala oddzielić podproces obsługi sporów od standardowego przebiegu windykacji.
Dlaczego to ważne
Łączy działania windykacyjne z formalnymi sprawami spornymi, umożliwiając osobną analizę sprawności ich rozpatrywania i przyczyn sporów.
Skąd pobrać
Dostępny w tabelach SAP Dispute Management, takich jak UDM_CASE_ATTR00. Wymaga modułu SAP Dispute Management.
Przykłady
400000000021400000000157400000000305
|
|||
|
Identyfikator systemu źródłowego
SourceSystemId
|
Identyfikator systemu źródłowego, z którego pobrano dane. | ||
|
Opis
Ten atrybut wskazuje system źródłowy, na przykład konkretną instancję SAP ECC, taką jak „ECCPRD100”. Jest przydatny w środowiskach z wieloma systemami ERP lub przy łączeniu danych z różnych źródeł. Umożliwia filtrowanie i porównywanie procesów w różnych systemach lub regionach. Ułatwia też śledzenie pochodzenia danych i diagnozowanie problemów z ich ekstrakcją.
Dlaczego to ważne
Dostarcza ważnych informacji o pochodzeniu danych, szczególnie w złożonych środowiskach IT. Ułatwia śledzenie danych i analizę dla poszczególnych systemów.
Skąd pobrać
Zwykle dodawany podczas ekstrakcji danych. W SAP można użyć nazwy systemu logicznego (LOGSYS).
Przykłady
SAPECC_PROD_100ECC_EU_200US_FIN_ERP
|
|||
|
Kategoria ryzyka
Ctlpc
|
Klasyfikacja ryzyka kredytowego klienta. | ||
|
Opis
Kategoria ryzyka (CTLPC w SAP) grupuje klientów według wiarygodności kredytowej i historii płatności. Klasyfikacja służy do automatycznej kontroli kredytowej i ustalania strategii windykacji. Analiza procesu według kategorii ryzyka może pokazać, czy klienci wysokiego ryzyka przechodzą inną ścieżkę procesu lub mają znacznie dłuższe cykle płatności. Informacje te pomagają zweryfikować trafność klasyfikacji ryzyka i dostosować intensywność windykacji do poziomu ryzyka.
Dlaczego to ważne
Umożliwia analizę procesu windykacji według poziomu ryzyka, co pomaga weryfikować modele ryzyka i odpowiednio dostosowywać strategie windykacyjne.
Skąd pobrać
Dane centralnego zarządzania kredytowego klienta: tabela KNKK, pole CTLPC.
Przykłady
001002WYSOKIE RYZYKO
|
|||
|
Kod spółki
Bukrs
|
Identyfikator jednostki prawnej (spółki), do której należy faktura. | ||
|
Opis
Kod spółki (BUKRS w SAP) oznacza niezależną jednostkę prawną, dla której sporządza się sprawozdania finansowe. To podstawowa jednostka organizacyjna w SAP Financials. Atrybut ten umożliwia filtrowanie i porównywanie wyników procesu w różnych jednostkach prawnych przedsiębiorstwa. Pozwala sprawdzić, czy procesy windykacyjne są ujednolicone oraz czy między spółkami występują istotne różnice, na przykład w DSO lub odsetku sporów.
Dlaczego to ważne
Pozwala analizować proces osobno dla każdej jednostki prawnej. Jest to istotne dla dużych, międzynarodowych organizacji, które chcą porównywać wyniki.
Skąd pobrać
Standardowe pole BUKRS w niemal wszystkich tabelach finansowych, w tym BKPF, BSEG, BSID i BSAD.
Przykłady
10002000US01
|
|||
|
Limit kredytowy
Klimk
|
Łączna kwota limitu kredytowego przyznanego klientowi. | ||
|
Opis
Limit kredytowy (KLIMK w SAP) to maksymalna kwota kredytu przyznana klientowi. Jest jednym z elementów zarządzania ryzykiem kredytowym. Atrybut ten jest niezbędny w dashboardzie „Trafność limitu kredytowego a straty z tytułu nieściągalnych należności”. Analiza związku między przyznanym limitem a odpisami pozwala ocenić skuteczność polityki kredytowej. Umożliwia też monitorowanie KPI „Wskaźnik rewizji limitów kredytowych” i sprawdzenie, czy początkowe oceny były trafne.
Dlaczego to ważne
Dostarcza kontekstu dotyczącego ryzyka kredytowego. Pozwala ocenić, czy polityka kredytowa ogranicza straty z tytułu nieściągalnych należności, nie hamując przy tym sprzedaży.
Skąd pobrać
Dane centralnego zarządzania kredytowego klienta: tabela KNKK, pole KLIMK.
Przykłady
10000.0050000.00250000.00
|
|||
|
Ostatnie odświeżenie danych
LastDataRefreshTimestamp
|
Znacznik czasu wskazujący, kiedy dane zostały ostatnio pobrane lub zaktualizowane w narzędziu process mining. | ||
|
Opis
Ten atrybut zapisuje datę i godzinę ostatniego wczytania danych. Informuje użytkowników biznesowych, jak aktualne są analizowane dane. Podczas przeglądania dashboardów i analiz znacznik czasu pomaga ustalić, czy dane obejmują najnowsze transakcje, czy występuje znane opóźnienie. To ważna metadana, która pomaga budować zaufanie do wyników analizy.
Dlaczego to ważne
Informuje o aktualności danych, co ma znaczenie przy podejmowaniu decyzji na podstawie najnowszych dostępnych informacji o procesie.
Skąd pobrać
Wartość jest generowana i zapisywana przez potok ekstrakcji i ładowania danych (ETL) podczas ich odświeżania.
Przykłady
2023-03-01T02:00:00Z2023-03-02T02:00:00Z2023-03-03T02:00:00Z
|
|||
|
Rodzaj dokumentu
Blart
|
Rodzaj dokumentu finansowego, na przykład faktura, nota kredytowa lub płatność. | ||
|
Opis
Rodzaj dokumentu (BLART w SAP) określa kategorię dokumentu księgowego. Na przykład „RV” może oznaczać fakturę sprzedaży, „DZ” płatność od klienta, a „DG” notę kredytową. Działania na potrzeby process mining są wyznaczane na podstawie danych, ale pierwotny rodzaj dokumentu dostarcza ważnego kontekstu. Można go wykorzystać do weryfikacji lub bardziej szczegółowej analizy finansowej. Pomaga zrozumieć charakter przetwarzanych transakcji i filtrować analizę, na przykład tak, aby uwzględniała tylko faktury sprzedaży.
Dlaczego to ważne
Dostarcza kontekstu finansowego przez klasyfikację transakcji. Można go użyć do filtrowania analizy lub weryfikacji nazw wyznaczonych działań.
Skąd pobrać
Standardowe pole BLART w tabeli nagłówków dokumentów BKPF.
Przykłady
Faktura sprzedażyPłatność od klientaNota kredytowaDokument księgowy
|
|||
|
Warunki płatności
Zterm
|
Kod uzgodnionych z klientem warunków płatności. | ||
|
Opis
Kod warunków płatności (ZTERM w SAP) określa zasady płatności, takie jak termin płatności i ewentualne rabaty za wcześniejszą zapłatę. Zwykle jest ustawiany w danych podstawowych klienta, a następnie kopiowany do faktur. Analiza według warunków płatności pomaga sprawdzić, jak różne zasady wpływają na zachowania płatnicze klientów. Przykładowo dashboard „Zgodność z warunkami płatności i ich wpływ” pokazuje, jak często klienci dotrzymują terminów i jaki ma to wpływ na liczbę dni opóźnienia. Wyniki mogą pomóc w wyborze warunków płatności dla poszczególnych segmentów klientów.
Dlaczego to ważne
Opisuje uzgodnione warunki płatności i pomaga ocenić, czy określone zasady sprzyjają terminowym płatnościom lub ograniczają liczbę sporów.
Skąd pobrać
Standardowe pole ZTERM, dostępne w danych podstawowych klienta (KNB1) i tabelach dokumentów finansowych (BSEG).
Przykłady
0001NT30ZD60
|
|||
Działania w procesie zarządzania kredytami i windykacji
| Działanie | Opis | ||
|---|---|---|---|
|
Odpisanie faktury
|
Oznacza decyzję o uznaniu nieopłaconej faktury za stratę i zaklasyfikowaniu jej jako nieściągalnej należności. Jest rejestrowane za pomocą określonego księgowania finansowego, które rozlicza pierwotną fakturę i przenosi kwotę na konto nieściągalnych należności. | ||
|
Dlaczego to ważne
To główne negatywne zdarzenie kończące proces. Oznacza niepowodzenie w zarządzaniu kredytowym lub windykacji i bezpośrednią stratę finansową. Analiza takich przypadków ma duże znaczenie dla usprawniania zasad kredytowych i strategii windykacyjnych.
Skąd pobrać
Zdarzenie jest zwykle rejestrowane bezpośrednio podczas księgowania lub wywnioskowane na podstawie transakcji rozliczeniowej. Rozliczenie odbywa się przy użyciu określonego kodu transakcji i kodu przyczyny wskazującego odpis. Odpis można potwierdzić, analizując dokument rozliczeniowy.
Rejestrowanie
Wyszukaj dokumenty rozliczeniowe, w których zastosowano określony kod przyczyny odpisu (BSEG-RSTGR) lub zaksięgowano zapis przeciwstawny na koncie kosztów nieściągalnych należności.
Typ zdarzenia
inferred
|
|||
|
Rozliczenie faktury
|
To zdarzenie oznacza pomyślne zamknięcie faktury, zwykle po otrzymaniu i przypisaniu pełnej płatności. Wnioskuje się o nim, gdy pozycja faktury zostaje przeniesiona z tabeli otwartych pozycji (BSID) do tabeli rozliczonych pozycji (BSAD). | ||
|
Dlaczego to ważne
To główne pozytywne zdarzenie kończące proces. Czas do jego wystąpienia jest jednym z podstawowych składników DSO. Analiza ścieżek prowadzących do tego zdarzenia pomaga wskazać dobre praktyki.
Skąd pobrać
To zdarzenie wywnioskowane. Rozliczenie można rozpoznać po numerze dokumentu rozliczeniowego (AUGBL) i dacie rozliczenia (AUGDT) dla pozycji faktury w tabeli rozliczonych pozycji BSAD.
Rejestrowanie
Jako znacznik czasu zdarzenia użyj daty rozliczenia (BSAD-AUGDT) konkretnej pozycji faktury.
Typ zdarzenia
inferred
|
|||
|
Upłynął termin płatności
|
Zdarzenie obliczane, które oznacza, że faktura stała się przeterminowana. Nie jest rejestrowane bezpośrednio przez system. Ustala się je, porównując termin płatności netto faktury z bieżącą datą lub znacznikiem czasu kolejnego działania. | ||
|
Dlaczego to ważne
To zdarzenie oznacza przejście od standardowego fakturowania do windykacji. Stanowi punkt wyjścia do obliczania liczby dni opóźnienia i rozpoczęcia procedur przypominających o płatności, a także podstawę raportów wiekowania należności.
Skąd pobrać
To zdarzenie obliczane. Ustala się je, porównując termin płatności netto (BSID-NETDT) otwartej pozycji faktury z datą systemową lub znacznikiem czasu innego zdarzenia.
Rejestrowanie
Zdarzenie oblicza się, porównując termin płatności netto faktury (BSID-NETDT) z osią czasu.
Typ zdarzenia
calculated
|
|||
|
Wykonanie przebiegu przypominania o płatności
|
To działanie oznacza uruchomienie automatycznego programu przypominającego o płatności przeterminowanej faktury. System zapisuje poziom przypomnienia, datę i inne szczegóły dla każdej faktury uwzględnionej w przebiegu. | ||
|
Dlaczego to ważne
Śledzenie działań przypominających o płatności jest niezbędne do oceny skuteczności strategii windykacyjnej. Pozwala ustalić, które poziomy przypomnień najskuteczniej skłaniają do zapłaty, i wskazać klientów, którzy nie reagują.
Skąd pobrać
To jawne zdarzenie. Szczegóły przebiegów przypominania o płatności są przechowywane w tabelach danych dotyczących tych działań, przede wszystkim w MHNK, która zawiera datę przebiegu (LAUFD) i poziom przypomnienia (MAHNS) dla każdej objętej nim faktury.
Rejestrowanie
Pobierz rekordy z tabeli MHNK i połącz je według kodu spółki, konta oraz daty przypomnienia o płatności.
Typ zdarzenia
explicit
|
|||
|
Zaksięgowanie faktury
|
Zdarzenie oznacza utworzenie dokumentu należności w module księgowości finansowej. Jest rejestrowane, gdy dokument rozliczeniowy z obszaru Sales and Distribution (SD) zostaje przekazany do księgowości lub gdy bezpośrednio wprowadzona zostaje faktura FI. W obu przypadkach powstają wpisy w tabelach BKPF i BSEG. | ||
|
Dlaczego to ważne
To główne zdarzenie rozpoczynające cykl życia faktury. Analiza czasu od tego momentu do otrzymania płatności ma zasadnicze znaczenie dla pomiaru DSO i ogólnej sprawności procesu.
Skąd pobrać
To jawne zdarzenie rejestrowane podczas tworzenia dokumentu finansowego. Znacznik czasu można pobrać z tabeli nagłówków dokumentów BKPF, z pola CPUDT lub BKTXT, dla numeru dokumentu faktury (BELNR).
Rejestrowanie
W tabeli BKPF należy wyszukać zdarzenia utworzenia dokumentów FI o odpowiednich typach, np. „RV” lub „DR”.
Typ zdarzenia
explicit
|
|||
|
Blokada płatności faktury
|
Oznacza nałożenie ręcznej lub automatycznej blokady, która uniemożliwia opłacenie faktury. Informację tę zapisuje wskaźnik blokady płatności ustawiony dla pozycji faktury w tabeli BSEG. | ||
|
Dlaczego to ważne
Blokady płatności są częstą przyczyną opóźnień i wyjątków w procesie. Ustalenie, kiedy i dlaczego blokowane są faktury, pomaga wykryć przyczyny opóźnień w płatnościach i usprawnić przepływy pieniężne.
Skąd pobrać
Ten status zwykle ustala się na podstawie zmiany pola blokady płatności (BSEG-ZLSPR) w pozycji faktury. Dzienniki zmian tego pola w tabelach CDHDR i CDPOS mogą zawierać dokładne znaczniki czasu.
Rejestrowanie
Wykryj zmiany pola BSEG-ZLSPR dla pozycji dokumentu faktury. Znaczniki czasu można pobrać z tabeli CDHDR.
Typ zdarzenia
inferred
|
|||
|
Niedotrzymanie obietnicy zapłaty
|
Zdarzenie obliczane, które oznacza, że klient nie zapłacił w uzgodnionym terminie, mimo złożonej obietnicy zapłaty. Wnioskuje się o nim na podstawie braku odpowiadającej jej płatności do wskazanej daty. | ||
|
Dlaczego to ważne
Wykrywanie niedotrzymanych obietnic jest niezbędne do zintensyfikowania działań windykacyjnych. Wysoki odsetek takich przypadków może wskazywać na problemy ze strategią windykacji lub sytuacją finansową klientów.
Skąd pobrać
To zdarzenie wywnioskowane lub obliczane. Ustala się je, porównując datę obietnicy z tabeli UDM_P2P_ATTR z datą rozliczenia płatności za fakturę. Jeśli do dnia wskazanego w obietnicy nie wpłynie płatność, uznaje się ją za niedotrzymaną.
Rejestrowanie
Porównaj datę obietnicy w UDM_P2P_ATTR z datą rozliczenia faktury. Jeśli rozliczenie nastąpiło po terminie obietnicy, uznaje się ją za niedotrzymaną.
Typ zdarzenia
calculated
|
|||
|
Rozstrzygnięcie sprawy sporu
|
Spór dotyczący faktury został zbadany i rozstrzygnięty. Zwykle odzwierciedla to zmiana statusu sprawy w SAP FSCM Dispute Management. | ||
|
Dlaczego to ważne
Rozstrzygnięcie sporu odblokowuje płatność. Pomiar czasu od utworzenia sprawy do jej zamknięcia to ważny KPI, który pomaga wykrywać nieefektywności w obsłudze sporów.
Skąd pobrać
To zdarzenie wywnioskowane ze zmiany statusu sprawy. Znacznik czasu można ustalić na podstawie dzienników zmian pola statusu w tabelach takich jak UDM_CASE oraz CDHDR/CDPOS.
Rejestrowanie
Na podstawie dzienników zmian ustal znacznik czasu zmiany statusu sprawy na „Closed” lub „Resolved”.
Typ zdarzenia
inferred
|
|||
|
Utworzenie pozycji resztowej
|
Zdarzenie występuje podczas rozliczania płatności, gdy klient wpłaca mniej niż wynosi kwota faktury, a pozostałe niewielkie saldo zostaje zaksięgowane jako nowa otwarta pozycja. Wnioskuje się o nim na podstawie szczegółów transakcji rozliczeniowej. | ||
|
Dlaczego to ważne
Pozycje resztowe wskazują na rozbieżności w płatnościach i powodują dodatkową pracę. Ich śledzenie pomaga wykrywać klientów, którzy regularnie płacą zbyt mało, oraz problemy z cenami lub fakturowaniem prowadzące do sporów.
Skąd pobrać
To zdarzenie wywnioskowane. Podczas transakcji rozliczeniowej, np. za pomocą F-28, pierwotna faktura zostaje rozliczona, a dla pozostałej kwoty powstaje nowy dokument otwartej pozycji. Utworzenie pozycji resztowej można wykryć, sprawdzając pozycje dokumentu rozliczeniowego.
Rejestrowanie
Przeanalizuj dokumenty rozliczeniowe (BKPF-AUGBL), aby znaleźć przypadki utworzenia nowej otwartej pozycji z odwołaniem do pierwotnej faktury.
Typ zdarzenia
inferred
|
|||
|
Utworzenie sprawy sporu
|
Oznacza formalne zarejestrowanie sporu klienta dotyczącego faktury, na przykład rozbieżności w cenie lub ilości. To jawne zdarzenie rejestrowane w module SAP FSCM Dispute Management. | ||
|
Dlaczego to ważne
Spory wstrzymują płatności i wymagają zaangażowania zasobów wewnętrznych. Rejestrowanie momentu ich powstania to pierwszy krok do analizy czasu rozpatrywania, przyczyn i wpływu na DSO.
Skąd pobrać
Jeśli używany jest SAP FSCM Dispute Management, to zdarzenie jest rejestrowane bezpośrednio. Utworzenie sprawy sporu zapisuje się w tabelach takich jak UDM_CASE lub SCMG_T_CASE_ATTR wraz ze znacznikiem czasu.
Rejestrowanie
Pobierz datę i godzinę utworzenia z tabel zarządzania sprawami, np. UDM_CASE, dla spraw powiązanych z fakturą.
Typ zdarzenia
explicit
|
|||
|
Zaksięgowanie dokumentu płatności przychodzącej
|
Oznacza pierwsze zarejestrowanie płatności od klienta w systemie, często zanim zostanie przypisana do konkretnych faktur. To jawne zdarzenie, podczas którego powstaje dokument płatności, na przykład typu DZ. | ||
|
Dlaczego to ważne
To zdarzenie oznacza otrzymanie środków. Czas między nim a końcowym zdarzeniem „Rozliczenie faktury” odpowiada procesowi przypisywania płatności do faktur, który może być istotnym wąskim gardłem.
Skąd pobrać
To jawne zdarzenie. Jest rejestrowane podczas tworzenia dokumentu płatności w tabeli BKPF, rozpoznawanego po określonym typie dokumentu, np. „DZ”. Znacznikiem czasu jest data księgowania (BKPF-BUDAT).
Rejestrowanie
W tabeli BKPF wyszukaj utworzone dokumenty o typach związanych z płatnościami, np. „DZ”.
Typ zdarzenia
explicit
|
|||
|
Zaksięgowanie faktury korygującej
|
Oznacza utworzenie faktury korygującej na koncie klienta, często w celu poprawienia błędu w fakturze lub rozstrzygnięcia sporu. Dokument jest tworzony bezpośrednio w module FI. | ||
|
Dlaczego to ważne
Faktury korygujące często wynikają z błędów na wcześniejszych etapach procesu, takich jak nieprawidłowa cena lub wysyłka. Analiza ich częstotliwości i przyczyn ma duże znaczenie dla usprawniania procesu i ograniczania utraty przychodów.
Skąd pobrać
To jawne zdarzenie rejestrowane podczas tworzenia dokumentu finansowego o typie faktury korygującej, np. „DG”. Znacznik czasu można pobrać z tabeli nagłówków dokumentów BKPF.
Rejestrowanie
W tabeli BKPF wyszukaj zdarzenia utworzenia dokumentów FI o typach faktur korygujących, np. „DG” lub „G2”.
Typ zdarzenia
explicit
|
|||
|
Zarejestrowanie kontaktu windykacyjnego
|
Pracownik windykacji skontaktował się z klientem w sprawie przeterminowanej faktury, na przykład telefonicznie lub e-mailem. Zwykle pracownik ręcznie rejestruje takie działanie w systemie. | ||
|
Dlaczego to ważne
To działanie mierzy pracę wykonywaną przez zespół windykacyjny. Analiza częstotliwości i czasu kontaktów w zestawieniu z późniejszymi płatnościami pomaga ocenić skuteczność działań pracowników.
Skąd pobrać
Jeśli używany jest SAP FSCM Collections Management, działanie jest rejestrowane jako „Customer Contact”. Szczegóły są przechowywane w tabelach dotyczących listy zadań windykacyjnych i historii kontaktów, często powiązanych z UDM_CASE.
Rejestrowanie
Pobierz rejestry kontaktów z klientami z odpowiednich tabel SAP FSCM Collections Management.
Typ zdarzenia
explicit
|
|||
|
Zarejestrowanie obietnicy zapłaty
|
Klient skontaktował się z działem windykacji i obiecał zapłacić do określonego dnia. To zdarzenie jest rejestrowane bezpośrednio, jeśli używany jest SAP FSCM Collections Management. | ||
|
Dlaczego to ważne
Obietnice zapłaty są ważnym wynikiem działań windykacyjnych. Analiza ich składania, realizacji i niedotrzymywania pomaga ocenić skuteczność działań windykatorów i prognozować wpływy gotówki.
Skąd pobrać
Jeśli używany jest SAP FSCM Collections Management, to zdarzenie jest rejestrowane bezpośrednio. Szczegóły obietnicy zapłaty są przechowywane w tabelach takich jak UDM_P2P_ATTR, powiązanych z partnerem biznesowym i fakturą.
Rejestrowanie
Pobierz znacznik czasu utworzenia z tabel obietnic zapłaty, takich jak UDM_P2P_ATTR w SAP FSCM.
Typ zdarzenia
explicit
|
|||
Instrukcje ekstrakcji danych
Gotowi do rozpoczęcia?
Skorzystaj z tego szablonu, aby usprawnić przygotowanie danych i szybciej odkryć możliwości poprawy procesu zarządzania kredytami i windykacji należności. Już dziś skróć czas oczekiwania na płatności i ogranicz ryzyko.
Przyspiesz wpływ płatności: usprawnij zarządzanie kredytami i windykację
Skróć cykl od przyznania kredytu do otrzymania płatności o 30% i zwiększ rentowność.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.