Szablon danych do zarządzania kredytami i windykacji
Szablon danych do zarządzania kredytami i windykacji
- Zalecane atrybuty w dzienniku zdarzeń
- Najważniejsze działania procesu do śledzenia w całym cyklu obsługi faktury
- Szczegółowe wskazówki dotyczące pobierania danych z SAP S/4HANA
Atrybuty zarządzania kredytami i windykacji
| Nazwa | Opis | ||
|---|---|---|---|
|
Czas zdarzenia
EventTime
|
Znacznik czasu wskazujący, kiedy wystąpiło działanie. | ||
|
Opis
Ten atrybut podaje dokładną datę i godzinę każdego zarejestrowanego działania. Jest niezbędny do ustalenia kolejności zdarzeń i obliczenia czasu między nimi. Czas zdarzenia służy do chronologicznego porządkowania działań, tworzenia mapy procesu i obliczania wskaźników efektywności. Na przykład pozwala obliczyć „Średni czas rozpatrywania sporów” przez zmierzenie czasu między znacznikami zdarzeń „Rejestracja sporu” i „Rozpatrzenie sporu”.
Dlaczego to ważne
Pozwala ustalić chronologiczną kolejność zdarzeń, niezbędną do obliczania czasu realizacji, analizy wyników procesu i wykrywania wąskich gardeł.
Skąd pobrać
Dane pochodzą z różnych pól daty i czasu w tabelach SAP, takich jak BUDAT (data księgowania) w BKPF lub CPUDT/CPUTM (data i godzina wprowadzenia) w różnych tabelach. Znaczniki czasu zawierają również tabele dzienników zmian CDHDR/CDPOS.
Przykłady
2023-04-15T10:00:00Z2023-05-01T14:30:00Z2023-05-10T09:15:00Z
|
|||
|
Nazwa działania
ActivityName
|
Nazwa konkretnego zdarzenia biznesowego, które wystąpiło w procesie zarządzania kredytem kupieckim i windykacji. | ||
|
Opis
Ten atrybut opisuje pojedynczy etap lub zadanie w procesie, na przykład „Wystawienie faktury”, „Rozpoczęcie procedury windykacyjnej” lub „Otrzymanie płatności”. Kolejność działań tworzy przebieg procesu dla każdego case. Analiza nazw działań jest podstawą process mining. Umożliwia odkrywanie mapy procesu, identyfikowanie wariantów i mierzenie przejść między etapami. Stanowi podstawę niemal każdej analizy procesu, w tym obliczania KPI, takich jak „Skuteczność windykacji”, który mierzy zdarzenia następujące po działaniu windykacyjnym.
Dlaczego to ważne
Określa etapy procesu, co pozwala przedstawić mapę procesu, analizować warianty i zrozumieć jego przebieg.
Skąd pobrać
Ustalana na podstawie kombinacji kodów transakcji (TCODE), dzienników zmian tabel (CDHDR/CDPOS) lub pól statusu w dokumentach SAP.
Przykłady
Wysłanie faktury do klientaRozpoczęcie procedury windykacyjnejOtrzymanie płatnościRejestracja sprawy spornej
|
|||
|
Numer faktury
InvoiceNumber
|
Unikalny identyfikator faktury dla klienta, pełniący funkcję głównego identyfikatora case w procesie zarządzania kredytem kupieckim i windykacji. | ||
|
Opis
Numer faktury, często określany jako numer dokumentu księgowego, jednoznacznie identyfikuje każdą transakcję należności. Łączy wszystkie zdarzenia procesu, od wystawienia faktury i wysyłania przypomnień po obsługę sporów oraz otrzymanie płatności lub odpisanie należności. W process mining analiza przebiegu każdego numeru faktury daje pełny obraz procesu od początku do końca. Pozwala wykryć typowe ścieżki, wąskie gardła w obsłudze płatności i różnice w sposobie obsługi faktur. Jest to ważne między innymi w dashboardach „Analiza wariantów procesu obsługi faktur” oraz „Wiek i status przeterminowanych faktur”.
Dlaczego to ważne
To podstawowy identyfikator case, który łączy wszystkie powiązane działania związane z kredytem i windykacją, umożliwiając analizę całego cyklu życia każdej należności.
Skąd pobrać
Zwykle znajduje się w tabeli BKPF (nagłówek dokumentu księgowego), w polu BELNR, lub w tabeli VBRK (dane nagłówka dokumentu rozliczeniowego), w polu VBELN.
Przykłady
190000012319000004561900000789
|
|||
|
Kwota faktury
InvoiceAmount
|
Łączna wartość faktury w walucie dokumentu. | ||
|
Opis
Ten atrybut określa łączną wartość pieniężną zafakturowanych towarów lub usług. Pozwala ocenić wpływ finansowy każdego case. Analiza kwoty faktury pomaga ustalać priorytety działań windykacyjnych, na przykład w dashboardzie „Priorytetyzacja portfela windykacyjnego”. Umożliwia też ocenę finansowych skutków nieefektywności procesu, takich jak łączna wartość faktur spornych lub środki zamrożone w przeterminowanych należnościach. Stanowi podstawę obliczania KPI, takich jak „Odsetek odpisanych faktur”.
Dlaczego to ważne
Określa wartość finansową każdego case, co jest niezbędne do ustalania priorytetów, oceny ryzyka i pomiaru wyników.
Skąd pobrać
Wyliczana na podstawie pozycji dokumentów księgowych w tabeli BSEG (pole DMBTR dla kwoty w walucie lokalnej lub WRBTR dla kwoty w walucie dokumentu).
Przykłady
1500.0025000.50750.75
|
|||
|
Liczba dni po terminie
DaysOverdue
|
Liczba dni, o które faktura przekroczyła termin płatności. | ||
|
Opis
To obliczana miara czasu między terminem płatności a bieżącą datą w przypadku otwartych faktur lub datą płatności w przypadku faktur rozliczonych. Wartość dodatnia oznacza opóźnienie w płatności. Liczba dni po terminie to podstawowy KPI w windykacji. Jest główną miarą w dashboardzie „Wiek i status zaległych faktur” i służy do ustalania priorytetów działań windykacyjnych. Analiza rozkładu tej miary pomaga ocenić ogólną kondycję portfela należności.
Dlaczego to ważne
To ważny wskaźnik skuteczności windykacji. Służy do analizy wieku należności, ustalania priorytetów pracy i pomiaru opóźnień w płatnościach.
Skąd pobrać
Obliczane podczas transformacji danych: (bieżąca data LUB data rozliczenia) - PaymentDueDate (BSEG-ZFBDT).
Przykłady
1530920
|
|||
|
Nazwa użytkownika
UserName
|
Identyfikator użytkownika, który wykonał działanie. | ||
|
Opis
Ten atrybut wskazuje użytkownika odpowiedzialnego za dany etap procesu, na przykład zaksięgowanie płatności lub uruchomienie przebiegu windykacji. W SAP jest zwykle zapisany w polu „User Name” (UNAME) lub „Entered by”. Analiza według użytkownika pomaga wskazać osoby lub zespoły osiągające dobre wyniki, obszary wymagające dodatkowych szkoleń oraz rozkład obciążenia pracą. Może też służyć do badania problemów ze zgodnością lub nieuprawnionych działań. Na przykład dashboard „Skuteczność rozmów windykacyjnych” pozwala śledzić wyniki poszczególnych pracowników windykacji.
Dlaczego to ważne
Łączy działania w procesie z konkretnymi osobami, umożliwiając analizę wyników pracy, obciążenia i zgodności.
Skąd pobrać
Zwykle znajduje się w tabelach nagłówkowych, takich jak BKPF (pole USNAM), lub w tabelach dzienników zmian, takich jak CDHDR (pole USERNAME).
Przykłady
JSMITHRROEBATCH_USER
|
|||
|
Numer klienta
CustomerNumber
|
Unikalny identyfikator konta klienta. | ||
|
Opis
Numer klienta identyfikuje partnera biznesowego, na którego wystawiono fakturę. Łączy transakcję finansową z rekordem danych podstawowych klienta. Ten atrybut jest niezbędny w analizie z perspektywy klienta, na przykład przy badaniu zachowań płatniczych konkretnych klientów lub segmentów. W dashboardach, takich jak „Trendy w zachowaniach płatniczych klientów”, pozwala śledzić klientów regularnie opóźniających płatności. Umożliwia też obliczanie KPI, takich jak „Obsługa klientów o wysokim priorytecie”, przez grupowanie faktur według klienta.
Dlaczego to ważne
Łączy transakcje z konkretnymi klientami, umożliwiając analizę zachowań płatniczych, segmentację i zarządzanie relacjami.
Skąd pobrać
Znajduje się w pozycjach dokumentów księgowych, na przykład w tabeli BSEG (pole KUNNR), lub w tabeli danych podstawowych klientów KNA1.
Przykłady
CUST100234CUST200567CUST300890
|
|||
|
Termin płatności
PaymentDueDate
|
Data, do której należy opłacić fakturę. | ||
|
Opis
Termin płatności jest obliczany na podstawie daty faktury i warunków płatności uzgodnionych z klientem. Stanowi punkt odniesienia przy ocenie terminowości płatności. Ta data jest podstawą analizy przeterminowanych należności. Służy do obliczania liczby dni opóźnienia i uruchamiania procedur windykacyjnych. Od tego atrybutu zależą dashboardy, takie jak „Wiek i status przeterminowanych faktur”, oraz KPI, takie jak „Średni Days Sales Outstanding (DSO)”.
Dlaczego to ważne
To podstawowa data przy ustalaniu, czy faktura jest przeterminowana. Służy do uruchamiania działań windykacyjnych i obliczania ważnych KPI.
Skąd pobrać
Znajduje się w pozycji klienta dokumentu księgowego, w tabeli BSEG (pole ZFBDT).
Przykłady
2023-05-302023-06-152023-07-01
|
|||
|
Kod spółki
CompanyCode
|
Jednostka organizacyjna reprezentująca prawnie niezależną spółkę, dla której sporządza się sprawozdania finansowe. | ||
|
Opis
Kod spółki to podstawowa jednostka organizacyjna w SAP Financials. Wszystkie transakcje finansowe, w tym faktury i płatności, są księgowane w ramach określonego kodu spółki. W process mining filtrowanie lub podział danych według kodu spółki pozwala porównywać wyniki procesu w różnych podmiotach prawnych należących do organizacji. Ułatwia to wskazanie dobrych praktyk, które można zastosować w innych podmiotach, oraz problemów dotyczących konkretnej spółki. To jeden z podstawowych filtrów w analizie procesów finansowych.
Dlaczego to ważne
Umożliwia porównanie wyników procesów i zgodności w różnych podmiotach prawnych organizacji.
Skąd pobrać
Znajduje się w większości tabel finansowych, takich jak BKPF i BSEG (pole BUKRS).
Przykłady
10002000US01DE01
|
|||
|
Limit kredytowy
CreditLimit
|
Maksymalna kwota kredytu przyznanego klientowi. | ||
|
Opis
Limit kredytowy to wartość zapisana w głównych danych kredytowych klienta. Określa łączne zaangażowanie kredytowe, jakie firma dopuszcza wobec danego klienta. Bezpośrednio odnoszą się do niego takie działania jak „Wniosek o limit kredytowy” i „Zatwierdzenie limitu kredytowego”. Ten atrybut dostarcza kontekstu do analizy ryzyka kredytowego. Dashboard „Analiza czasu cyklu zatwierdzania kredytu” śledzi proces ustalania lub zmiany limitu. Analiza limitu w zestawieniu z zaległymi kwotami pomaga ocenić ryzyko całego portfela.
Dlaczego to ważne
Określa zatwierdzony poziom ryzyka kredytowego klienta. Jest podstawą analizy procesu zatwierdzania kredytu i łącznego zaangażowania kredytowego.
Skąd pobrać
Wartość jest przechowywana w module SAP Credit Management (FSCM), na przykład w tabeli UKM_BP_CMS_SGMT, w polu CREDIT_LIMIT.
Przykłady
50000.00100000.00250000.00
|
|||
|
Ostatnia aktualizacja danych
LastDataUpdate
|
Znacznik czasu ostatniego odświeżenia danych lub ich pobrania z systemu źródłowego. | ||
|
Opis
Ten atrybut wskazuje, kiedy ostatnio zaktualizowano zbiór danych. Informuje użytkowników, jak aktualne są analizowane dane. To ważne metadane dla każdego dashboardu i każdej analizy. Pokazują, jaki okres obejmują dane, i zapobiegają błędnym wnioskom opartym na nieaktualnych informacjach. Na przykład analiza przeterminowanych faktur ma sens tylko wtedy, gdy wiadomo, kiedy ostatnio pobrano dane.
Dlaczego to ważne
Pozwala ocenić aktualność danych, co ma znaczenie przy podejmowaniu trafnych decyzji na podstawie danych.
Skąd pobrać
Wartość jest generowana i zapisywana podczas procesu ekstrakcji, transformacji i ładowania danych (ETL).
Przykłady
2023-10-27T02:00:00Z2023-10-26T02:00:00Z
|
|||
|
Poziom windykacji
DunningLevel
|
Wskazuje bieżący etap procedury windykacyjnej dla przeterminowanej faktury. | ||
|
Opis
Poziom windykacji określa intensywność działań, które zwykle przechodzą od prostego przypomnienia do formalnego wezwania prawnego. Każdy poziom odpowiada działaniu określonemu w procedurze windykacyjnej. Śledzenie tego atrybutu jest niezbędne do monitorowania skuteczności i zgodności procedury. Dashboard „Skuteczność procedury windykacyjnej” służy do analizy wskaźników płatności na poszczególnych poziomach, a dashboard „Zgodność procedury windykacyjnej” pozwala sprawdzić, czy zachowano ich prawidłową kolejność.
Dlaczego to ważne
Pokazuje postęp działań windykacyjnych i pozwala analizować ich skuteczność oraz zgodność procesu.
Skąd pobrać
Informacje te są przechowywane w tabelach danych windykacyjnych, takich jak MHND. Ostatni poziom windykacji dla pozycji można znaleźć w tabeli BSEG (pole MANST).
Przykłady
123 - Ostateczne wezwanieDziałania prawne
|
|||
|
Przyczyna odpisania należności
WriteOffReason
|
Kod przyczyny wyjaśniający, dlaczego fakturę odpisano jako nieściągalną. | ||
|
Opis
Gdy należność zostaje uznana za nieściągalną, usuwa się ją z ksiąg i przypisuje kod przyczyny, na przykład „Upadłość”, „Odpisanie niskiej kwoty” lub „Nierozstrzygnięty spór”. Ten atrybut jest niezbędny w dashboardzie „Analiza odpisanych faktur”. Analiza liczby i wartości odpisów według przyczyny pozwala wykryć słabe punkty polityki kredytowej lub strategii windykacji i podjąć działania ograniczające przyszłe straty.
Dlaczego to ważne
Wyjaśnia źródła strat finansowych wynikających z nieściągalnych należności, co pomaga doskonalić politykę kredytową i windykacyjną.
Skąd pobrać
Informacja ta jest zwykle zapisywana w polach kodu przyczyny (BSEG-RSTGR) podczas księgowania operacji finansowej, na przykład F-30, służącej do odpisania należności.
Przykłady
UPADŁOŚĆNISKA_KWOTASTRATA_SPORNA
|
|||
|
Przyczyna sporu
DisputeReason
|
Kod przyczyny wskazujący, dlaczego klient kwestionuje fakturę. | ||
|
Opis
Gdy klient kwestionuje fakturę, zwykle przypisuje się przyczynę, która określa charakter problemu, na przykład „Nieprawidłowa cena”, „Uszkodzony towar” lub „Zduplikowana faktura”. Obsługa odbywa się w module SAP Dispute Management. Analiza przyczyn sporów pomaga wykrywać źródła niezadowolenia klientów i opóźnień w płatnościach. W dashboardzie „Liczba i rozpatrywanie sporów dotyczących faktur” można podzielić dane według tego atrybutu, aby wskazać powtarzające się problemy na wcześniejszych etapach procesu od zamówienia do płatności, które wymagają rozwiązania.
Dlaczego to ważne
Ujawnia przyczyny sporów dotyczących faktur, pomagając wykrywać i usuwać źródłowe problemy operacyjne.
Skąd pobrać
Dane pochodzą z modułu SAP Dispute Management, prawdopodobnie z tabel takich jak UDM_SCASE_ATTR lub podobnych, na podstawie atrybutów sprawy spornej.
Przykłady
PRC_ERR - Błąd cenyQTY_DIF - Różnica ilościSHIP_DMG - Uszkodzona przesyłka
|
|||
|
Segment klienta
CustomerSegment
|
Klasyfikacja klienta, na przykład według wielkości, branży lub znaczenia strategicznego. | ||
|
Opis
Segment klienta to klasyfikacja stosowana w marketingu lub sprzedaży do grupowania klientów o podobnych cechach. Podstawą mogą być między innymi roczne przychody, branża, lokalizacja geograficzna lub status relacji, na przykład Gold, Silver albo Bronze. Podział danych według tego atrybutu pomaga wykrywać wzorce charakterystyczne dla poszczególnych grup. Na przykład dashboard „Analiza odpisów faktur” może pokazać, czy dany segment odpowiada za nieproporcjonalnie dużą część odpisów. Takie informacje pomagają podejmować decyzje dotyczące zasad kredytowych dla tego segmentu.
Dlaczego to ważne
Umożliwia analizę wyników procesu i zachowań klientów w różnych grupach, dostarczając informacji przydatnych przy podejmowaniu decyzji.
Skąd pobrać
Zwykle pochodzi z danych podstawowych klienta w tabeli KNA1, często z pola klasyfikacji lub atrybutu, takiego jak KDKG1-KDKG5 (grupa klienta 1–5).
Przykłady
Duże przedsiębiorstwoMałe i średnie przedsiębiorstwoAdministracja publicznaKlient strategiczny
|
|||
|
System źródłowy
SourceSystem
|
Wskazuje system, z którego pochodzą dane. | ||
|
Opis
Ten atrybut określa źródłowy system informatyczny, w tym przypadku SAP S/4HANA. Ma szczególne znaczenie w środowiskach, w których dane są łączone z wielu systemów, na przykład różnych instancji ERP lub osobnego systemu CRM. W analizie procesów pozwala rozróżnić procesy obejmujące wiele systemów lub ograniczyć analizę do konkretnej instancji. Zapewnia informacje o pochodzeniu danych i dostarcza kontekstu podczas ich weryfikacji oraz rozwiązywania problemów.
Dlaczego to ważne
Informuje o pochodzeniu danych, co ułatwia ich interpretację w środowisku wielosystemowym i wspiera zarządzanie danymi.
Skąd pobrać
Zwykle jest to stała wartość dodawana podczas ekstrakcji danych, która identyfikuje konkretną instancję SAP S/4HANA, na przykład za pomocą identyfikatora systemu (SID).
Przykłady
S4H_PROD_100S4HANA_FINANCE_EUSAP_ECC_US
|
|||
|
Waluta faktury
InvoiceCurrency
|
Waluta, w której wystawiono fakturę. | ||
|
Opis
Ten atrybut określa kod waluty faktury, na przykład USD lub EUR. Dostarcza kontekstu potrzebnego do interpretacji kwot, zwłaszcza w organizacjach międzynarodowych. Większość analiz jest prowadzona w ujednoliconej walucie lokalnej, ale waluta dokumentu pozwala zrozumieć pierwotną transakcję i analizować wpływ różnic kursowych. Uzupełnia informacje zawarte w atrybucie kwoty faktury.
Dlaczego to ważne
Dostarcza kontekstu niezbędnego do interpretacji kwoty faktury i prowadzenia dokładnych analiz finansowych w środowisku wielowalutowym.
Skąd pobrać
Zwykle znajduje się w tabelach nagłówkowych, takich jak BKPF (pole WAERS), lub w tabelach pozycji, takich jak BSEG (pole PSWSL).
Przykłady
USDEURGBP
|
|||
|
Wykonane automatycznie
IsAutomated
|
Flaga wskazująca, czy działanie wykonał użytkownik systemowy, czy człowiek. | ||
|
Opis
Ten atrybut logiczny odróżnia działania wykonywane automatycznie przez system, na przykład zaplanowany przebieg monitów lub automatyczne księgowanie płatności, od działań wykonywanych ręcznie przez użytkownika, takich jak telefon windykacyjny. Analiza tego atrybutu pozwala zmierzyć poziom automatyzacji procesu. Ułatwia porównanie efektywności i spójności kroków automatycznych oraz ręcznych, wskazanie możliwości dalszej automatyzacji i ocenę rzeczywistego nakładu pracy przy windykacji.
Dlaczego to ważne
Pozwala określić poziom automatyzacji procesu i analizować jej wpływ na efektywność oraz koszty.
Skąd pobrać
Jest to atrybut pochodny, zwykle wyznaczany na podstawie pola „UserName”. Jeśli identyfikator użytkownika znajduje się na zdefiniowanej liście użytkowników systemowych lub wsadowych, na przykład „BATCH_USER”, flaga przyjmuje wartość true.
Przykłady
truefalse
|
|||
Działania w procesie zarządzania kredytami i windykacji
| Działanie | Opis | ||
|---|---|---|---|
|
Odpisanie faktury
|
To działanie oznacza decyzję o uznaniu niezapłaconej faktury za stratę i zaklasyfikowaniu jej jako nieściągalnej należności. Jest rejestrowane po zaksięgowaniu określonego rodzaju dokumentu rozliczającego, często z unikalnym kodem przyczyny. | ||
|
Dlaczego to ważne
Odpisy oznaczają bezpośrednią stratę finansową. Analiza ich częstotliwości, wartości i poprzedzających je działań pomaga wykrywać klientów obciążonych ryzykiem oraz problemy w procesie windykacji.
Skąd pobrać
Zdarzenie można ustalić, analizując dokument rozliczający fakturę. Odpis wskazuje określone konto księgi głównej lub kod przyczyny (BSEG-RSTGR) użyty w dokumencie rozliczającym.
Rejestrowanie
Należy znaleźć dokument rozliczający i sprawdzić, czy zawiera określony kod przyczyny lub księgowanie na konto nieściągalnych należności.
Typ zdarzenia
inferred
|
|||
|
Otrzymanie płatności
|
To działanie oznacza otrzymanie środków od klienta i przypisanie ich do otwartej faktury. Jest rejestrowane przez utworzenie dokumentu rozliczającego należność z faktury. | ||
|
Dlaczego to ważne
To ważny etap, który bezpośrednio wpływa na przepływy pieniężne i DSO. Analiza czasu do otrzymania płatności oraz poprzedzających ją działań pokazuje skuteczność całego procesu windykacji.
Skąd pobrać
Zdarzenie można ustalić na podstawie dokumentu rozliczającego zaksięgowanego dla faktury. Data rozliczenia (AUGDT) dla danej faktury, zapisana w tabeli rozliczonych pozycji BSAD, stanowi znacznik czasu.
Rejestrowanie
Dla odpowiedniego numeru dokumentu faktury (BELNR) należy znaleźć datę rozliczenia (AUGDT) w tabeli BSAD.
Typ zdarzenia
inferred
|
|||
|
Rejestracja sprawy spornej
|
To działanie oznacza formalne zakwestionowanie faktury przez klienta i utworzenie sprawy w SAP Dispute Management. Jest rejestrowane w chwili utworzenia nowej sprawy spornej powiązanej z dokumentem faktury. | ||
|
Dlaczego to ważne
Rejestracja sporów pomaga analizować wyjątki w procesie. Analiza liczby sporów, ich przyczyn i czasu rozpatrywania pozwala wykryć źródła problemów, takie jak błędy cenowe lub wysyłkowe.
Skąd pobrać
To zdarzenie jest rejestrowane bezpośrednio w tabelach SAP Dispute Management. Znacznikiem czasu jest data utworzenia sprawy w tabelach takich jak UKM_CASE lub FDM_DCOBJ, powiązanej z fakturą.
Rejestrowanie
Należy użyć znacznika czasu utworzenia sprawy spornej z tabeli UKM_CASE, filtrując dane według typu sprawy.
Typ zdarzenia
explicit
|
|||
|
Rozliczenie faktury
|
To końcowy, pomyślny rezultat dla faktury: została w pełni opłacona i usunięta z otwartych pozycji. Taki stan rozpoznaje się po powiązanym dokumencie i dacie rozliczenia. | ||
|
Dlaczego to ważne
To główny punkt końcowy procesu, który zamyka cykl życia faktury. Analiza ścieżek i czasu potrzebnego na osiągnięcie tego stanu ma podstawowe znaczenie dla usprawniania procesu.
Skąd pobrać
Nie jest to odrębne zdarzenie, lecz stan wywnioskowany z tabel finansowych. Fakturę uznaje się za rozliczoną, gdy znajduje się w tabeli rozliczonych pozycji klientów BSAD i ma prawidłową datę rozliczenia (AUGDT).
Rejestrowanie
Jako znacznik czasu końcowego działania należy użyć daty rozliczenia (AUGDT) z tabeli BSAD.
Typ zdarzenia
inferred
|
|||
|
Upłynął termin płatności
|
Zdarzenie wyliczane, które występuje, gdy bieżąca data przekracza termin płatności netto faktury, a płatność rozliczająca nie została zaksięgowana. Oznacza zmianę statusu faktury z „bieżącej” na „przeterminowaną”. | ||
|
Dlaczego to ważne
To zdarzenie uruchamia wszystkie działania windykacyjne i przypomnienia o płatności. Jest niezbędne do analizy zachowań płatniczych, przyczyn opóźnień i skuteczności przypomnień wysyłanych z wyprzedzeniem.
Skąd pobrać
Nie jest to zdarzenie rejestrowane bezpośrednio. Ustala się je przez porównanie terminu płatności netto (np. pola ZFBDT w tabeli BSID) ze znacznikiem czasu analizy lub późniejszego działania.
Rejestrowanie
Zdarzenie można wyznaczyć, porównując termin płatności netto faktury (BSID-ZFBDT) z bieżącym znacznikiem czasu lub znacznikiem czasu późniejszego zdarzenia.
Typ zdarzenia
calculated
|
|||
|
Wystawienie faktury
|
To działanie oznacza utworzenie faktury dla klienta i rozpoczyna proces windykacji. Zdarzenie jest rejestrowane, gdy w systemie SAP S/4HANA zostaje zaksięgowany nowy dokument księgowy typu faktura. | ||
|
Dlaczego to ważne
To główne zdarzenie rozpoczynające proces od faktury do płatności. Analiza czasu od tego momentu do otrzymania płatności ma zasadnicze znaczenie przy pomiarze Days Sales Outstanding (DSO) i ogólnej sprawności procesu.
Skąd pobrać
Zdarzenie jest rejestrowane bezpośrednio. Datę i godzinę utworzenia można znaleźć w nagłówku dokumentu księgowego w tabeli BKPF, dla odpowiedniego numeru dokumentu (BELNR). Typy dokumentów, takie jak „RV”, zwykle oznaczają faktury dla klientów.
Rejestrowanie
Dla dokumentu faktury należy użyć znacznika czasu utworzenia dokumentu (CPUDT, CPUTM) z tabeli BKPF.
Typ zdarzenia
explicit
|
|||
|
Rozmowa windykacyjna z klientem
|
Oznacza bezpośredni kontakt pracownika windykacji z klientem w sprawie przeterminowanej faktury. Zwykle nie jest to standardowe zdarzenie SAP, dlatego wymaga własnego rejestrowania lub integracji z systemem CRM. | ||
|
Dlaczego to ważne
Ręczne działania są kosztowną częścią procesu windykacji. Śledzenie rozmów pozwala ocenić skuteczność pracowników windykacji i ustalić, które konta wymagają ręcznej obsługi.
Skąd pobrać
W standardowej konfiguracji S/4HANA te informacje zwykle nie są dostępne. Mogą być przechowywane w tabelach niestandardowych, jako notatki na liście zadań windykacyjnych lub w zewnętrznym systemie CRM, który trzeba zintegrować.
Rejestrowanie
Wymaga analizy rozszerzeń systemu, notatek lub danych z zewnętrznego systemu, w którym rejestrowane są działania windykacyjne.
Typ zdarzenia
explicit
|
|||
|
Rozpatrzenie sporu
|
To działanie oznacza zamknięcie sprawy spornej, ponieważ roszczenie klienta zostało uznane lub odrzucone. Jest rejestrowane, gdy status sprawy zmienia się na „zamknięta” lub „rozpatrzona”. | ||
|
Dlaczego to ważne
Czas rozpatrywania sporów jest ważnym wskaźnikiem zadowolenia klientów i sprawności operacyjnej. Długie postępowanie może opóźniać płatności i pogarszać relacje z klientami.
Skąd pobrać
Zdarzenie można ustalić na podstawie zmiany statusu sprawy spornej. Znacznik czasu zmiany statusu na „Closed” lub „Confirmed” w tabeli UKM_CASE wskazuje moment rozpatrzenia sprawy.
Rejestrowanie
W tabeli UKM_CASE lub powiązanych tabelach dziennika zmian statusu należy znaleźć znacznik czasu zmiany na końcowy status oznaczający rozpatrzenie sprawy.
Typ zdarzenia
inferred
|
|||
|
Rozpoczęcie procedury windykacyjnej
|
To działanie oznacza formalne uruchomienie automatycznej procedury windykacyjnej dla przeterminowanej faktury. Jest rejestrowane, gdy przebieg windykacji obejmuje fakturę i przypisuje jej poziom windykacji. | ||
|
Dlaczego to ważne
To początek automatycznej windykacji. Śledzenie działań windykacyjnych pozwala ocenić skuteczność strategii i sprawdzić jej zgodność z zasadami wewnętrznymi.
Skąd pobrać
To zdarzenie jest rejestrowane bezpośrednio w tabelach danych windykacyjnych. Data przebiegu (LAUFD) z tabeli nagłówkowej MHNK, powiązana z fakturą, wskazuje, kiedy wykonano procedurę.
Rejestrowanie
Dla danej faktury należy pobrać datę przebiegu windykacji (MHNK-LAUFD) i poziom windykacji (MHNK-MAHNS).
Typ zdarzenia
explicit
|
|||
|
Wysłanie faktury do klienta
|
Oznacza moment przekazania faktury klientowi, na przykład w formie wydruku, e-maila lub przez EDI. Zdarzenie jest zwykle rejestrowane w dziennikach ustalania komunikatów SAP, które wskazują, kiedy przetworzono komunikat wyjściowy. | ||
|
Dlaczego to ważne
Opóźnienie między wystawieniem a wysłaniem faktury może wydłużyć cały cykl płatności. Śledzenie tego czasu pomaga wykryć wąskie gardła w komunikacji z klientem i dystrybucji dokumentów.
Skąd pobrać
Zdarzenie można ustalić na podstawie daty i godziny przetworzenia w tabeli statusów komunikatów NAST, gdzie typ komunikatu wyjściowego odpowiada fakturze dla klienta. Wymaga to prawidłowej konfiguracji ustalania komunikatów.
Rejestrowanie
W tabeli NAST należy znaleźć pomyślnie przetworzony rekord powiązany z numerem dokumentu rozliczeniowego faktury.
Typ zdarzenia
inferred
|
|||
|
Zaksięgowanie płatności
|
Oznacza zaksięgowanie płatności w księdze głównej. Często następuje równocześnie z otrzymaniem środków, ale może być osobnym etapem, który wiąże się z opóźnieniem. | ||
|
Dlaczego to ważne
Opóźnienie między otrzymaniem środków a ich zaksięgowaniem może zniekształcić sprawozdawczość finansową. Pomiar czasu tego etapu pomaga ocenić sprawność i dokładność procesów księgowych.
Skąd pobrać
Zdarzenie można ustalić na podstawie daty księgowania (BUDAT) lub daty utworzenia (CPUDT) dokumentu rozliczającego w tabeli BKPF. Numer dokumentu rozliczającego znajduje się w polu BSAD-AUGBL.
Rejestrowanie
Należy użyć daty księgowania (BUDAT) z tabeli BKPF dla dokumentu rozliczającego fakturę.
Typ zdarzenia
inferred
|
|||
|
Zarejestrowanie obietnicy zapłaty
|
Zdarzenie występuje, gdy pracownik windykacji zapisuje obietnicę klienta, że zapłaci przeterminowaną należność w określonym terminie. Jest to jawnie rejestrowana czynność w module SAP Collections Management. | ||
|
Dlaczego to ważne
Obietnice zapłaty są jednym z rezultatów działań windykacyjnych. Analiza ich częstotliwości, realizacji i wpływu na terminy płatności pomaga doskonalić strategię windykacji.
Skąd pobrać
To zdarzenie jest rejestrowane bezpośrednio w SAP Collections Management. Datę utworzenia obietnicy zapłaty można pobrać z tabel takich jak UDM_P2P_ATTR.
Rejestrowanie
Należy użyć daty utworzenia z tabel obietnic zapłaty, takich jak UDM_P2P_ATTR, powiązanych z fakturą.
Typ zdarzenia
explicit
|
|||
Instrukcje pobierania danych
Gotowi do rozpoczęcia?
Skorzystajcie z tego szablonu, aby przygotować dane do analizy i wykorzystać process mining w zarządzaniu kredytami i windykacji. Zacznijcie usprawniać przepływy pieniężne i ograniczać nieściągalne należności.
Poprawa przepływów pieniężnych: usprawnijcie zarządzanie kredytami i windykację
Wykryjcie nieefektywności, skróćcie czas cyklu o 30% i poprawcie przepływy pieniężne.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.