Szablon danych do obsługi płatności
Szablon danych do obsługi płatności
To ogólny szablon danych do process mining dla procesu Obsługa płatności. Aby uzyskać dokładniejsze wskazówki, skorzystaj z szablonów dla konkretnych systemów.
Wybierz konkretny system- Szczegółowe definicje pól do śledzenia transakcji
- Uniwersalne mapowanie działań w cyklu realizacji płatności
- Skalowalne struktury danych zgodne z dowolnym systemem finansowym
Atrybuty obsługi płatności
| Nazwa | Opis | ||
|---|---|---|---|
| Data ostatniej aktualizacji danych LastDataUpdate | Znacznik czasu wskazujący, kiedy rekord został ostatnio wyodrębniony lub odświeżony. | ||
| Opis Ten atrybut pozwala ocenić aktualność danych używanych w analizie. Wskazuje, kiedy dane załadowano do narzędzia process mining lub kiedy rekord został ostatnio zmodyfikowany w źródłowej bazie danych. Ta informacja jest niezbędna do zarządzania danymi i budowania do nich zaufania. Analitycy mogą sprawdzić, czy korzystają z danych w czasie rzeczywistym, czy z migawki z poprzedniego dnia. Ma to szczególne znaczenie przy monitorowaniu aktywnych płatności, które mogą utknąć w oczekującym statusie. Atrybut nie służy bezpośrednio do obliczania przebiegu procesu. Jest polem kontrolnym metadanych, które pomaga upewnić się, że dashboardy pokazują aktualny status operacji płatniczych. Dlaczego to ważne Pozwala sprawdzić aktualność danych i ułatwia diagnozowanie opóźnień w potoku danych. Skąd pobrać Generowany podczas ekstrakcji danych lub procesu ETL. Przykłady 2023-10-27T12:00:00Z2023-10-27 23:59:592023-10-28 06:00:0010/27/20232023-11-01 01:00:00.000 | |||
| Identyfikator transakcji płatniczej PaymentTransactionId | Unikalny identyfikator konkretnego zlecenia płatniczego lub sprawy transakcyjnej. | ||
| Opis Ten atrybut jest głównym kluczem łączącym wszystkie działania w ramach jednego cyklu płatności. Dzięki niemu narzędzia process mining mogą odtworzyć pełny przebieg płatności, od jej zainicjowania po ostateczne rozliczenie lub niepowodzenie. W analizie identyfikator służy do grupowania poszczególnych zdarzeń w jedną sprawę. Umożliwia wizualizację przebiegu procesu i jest niezbędny do obliczania czasu realizacji każdej transakcji. Bez unikalnego identyfikatora nie da się rozróżnić tysięcy płatności przetwarzanych jednocześnie. Ten identyfikator zazwyczaj pozostaje niezmienny przez cały okres obsługi płatności. W złożonych scenariuszach obejmujących wiele systemów może być jednak konieczne użycie klucza złożonego lub powiązanie danych z unikalnym numerem referencyjnym end-to-end. Dlaczego to ważne To podstawowy identyfikator sprawy (Case ID), potrzebny do utworzenia modelu procesu i śledzenia poszczególnych płatności. Skąd pobrać Zazwyczaj znajduje się w nagłówku transakcji, tabeli zleceń płatniczych lub głównym dzienniku księgowym. Przykłady TRX-8859201PAY-2023-X9910029384f47ac10b-58cc-4372-a567-0e02b2c3d479INSTR-5542 | |||
| Nazwa działania ActivityName | Konkretna czynność, zmiana statusu lub zdarzenie w cyklu płatności. | ||
| Opis Ten atrybut opisuje czynność lub zmianę stanu płatności w określonym momencie. Przykłady obejmują utworzenie zlecenia, sprawdzenie poprawności danych, autoryzację lub końcowe rozliczenie. W process mining atrybut ten służy do określania węzłów na mapie procesu. Analiza kolejności działań pozwala analitykom rozpoznać typowe warianty, pętle związane z ponownym przetwarzaniem płatności oraz wąskie gardła, w których płatności długo oczekują. Aby uzyskać spójny obraz procesu, często trzeba ujednolicić nazwy pochodzące z różnych systemów źródłowych. Na przykład jeden system może używać nazwy „Auth”, a inny „Authorization”. Podczas przekształcania danych należy ujednolicić te określenia. Dlaczego to ważne Określa węzły na mapie procesu i umożliwia analizę przebiegu procesu oraz jego wariantów. Skąd pobrać Znajduje się w dziennikach audytowych, tabelach historii statusów lub tabelach śledzenia zdarzeń. Przykłady Płatność utworzonaPłatność autoryzowanaPłatność nieudanaRozliczenie potwierdzoneBłąd walidacji | |||
| System źródłowy SourceSystem | Nazwa aplikacji lub systemu, z którego pochodzą dane o zdarzeniu. | ||
| Opis Ten atrybut wskazuje techniczne źródło rekordu. W procesach płatniczych end-to-end dane często przepływają przez wiele systemów, na przykład bramkę płatniczą, silnik wykrywania nadużyć i księgę główną. Analiza danych według systemu pozwala wyodrębnić problemy techniczne. Jeśli na przykład opóźnienia regularnie występują w silniku wykrywania nadużyć, ale nie w księdze głównej, można skuteczniej ustalić ich przyczynę. Atrybut pomaga też sprawdzić spójność danych podczas łączenia wielu źródeł. Jeśli pole nie występuje w danych źródłowych, zazwyczaj dodaje się je podczas ekstrakcji i przekształcania danych. Służy do śledzenia pochodzenia danych na potrzeby audytu i debugowania. Dlaczego to ważne Niezbędny do analizy wielu systemów i ustalenia, który z nich powoduje opóźnienia lub błędy. Skąd pobrać Często ustawiany na stałe podczas procesu ETL lub pobierany z metadanych systemu. Przykłady PaymentGateway_01CoreBankingSystemFraudEngineSwiftInterfaceERP_SAP | |||
| Znacznik czasu zdarzenia EventTimestamp | Dokładna data i godzina wystąpienia działania lub zmiany statusu. | ||
| Opis Ten atrybut zapisuje dokładny moment wystąpienia zdarzenia w systemie płatniczym. Wyznacza chronologię procesu i pozwala prawidłowo uporządkować zdarzenia w ramach sprawy. W analizie znacznik czasu stanowi podstawę wszystkich obliczeń związanych z czasem. Służy do określania odstępów między działaniami, całkowitego czasu realizacji procesu end-to-end oraz zgodności z umowami SLA. Dokładne znaczniki czasu pomagają ustalić, kiedy pojawiają się wąskie gardła. Warto zachować wysoką precyzję, zwłaszcza w systemach płatności automatycznych i transakcjach o dużej częstotliwości, gdzie liczą się milisekundy. Jeśli dostępne są tylko daty bez godzin, do ustalenia kolejności działań z tego samego dnia może być potrzebna dodatkowa reguła sortowania. Dlaczego to ważne Niezbędny do porządkowania zdarzeń i obliczania wskaźników KPI opartych na czasie, takich jak czas realizacji procesu. Skąd pobrać Znajduje się w dziennikach transakcji, tabelach historii lub ścieżkach audytowych systemu. Przykłady 2023-10-15T08:30:00Z2023-10-15 14:45:12.5502023-11-01T09:00:00+00:0015.10.2023 20:30:002023-10-16 10:15:00 | |||
| Kod błędu ErrorCode | Kod lub przyczyna wygenerowana w przypadku niepowodzenia lub odrzucenia płatności. | ||
| Opis Ten atrybut zapisuje techniczną lub biznesową przyczynę niepowodzenia procesu. Jest uzupełniany, gdy płatność zostaje odrzucona, nie przechodzi walidacji lub występuje błąd transmisji. Analiza kodów błędów to podstawowy sposób na ograniczenie „odsetka nieudanych płatności” i „odsetka ponownego przetwarzania”. Grupowanie powtarzających się kodów pomaga wykrywać problemy systemowe, takie jak nieprawidłowe dane podstawowe lub problemy z łącznością z zewnętrznymi izbami rozliczeniowymi. W przypadku prawidłowego przebiegu procesu pole to zazwyczaj pozostaje puste. Jego wypełnienie często wskazuje na odstępstwo od standardowego przebiegu i uruchamia podprocesy obsługi wyjątków. Dlaczego to ważne Podstawowy atrybut do analizy przyczyn źródłowych niepowodzeń i ponownego przetwarzania. Skąd pobrać Znajduje się w dziennikach błędów, komunikatach o odrzuceniu lub treści odpowiedzi. Przykłady INSUFFICIENT_FUNDSINVALID_ACCOUNTFRAUD_SUSPICIONTIMEOUTDUPLICATE_REF | |||
| Kod waluty CurrencyCode | Trzyliterowy kod ISO określający walutę płatności. | ||
| Opis Ten atrybut określa walutę kwoty płatności, na przykład USD, EUR lub GBP. Jest niezbędny do prawidłowego raportowania finansowego i uruchamiania określonych workflow dla płatności transgranicznych. Analiza często wymaga filtrowania według waluty, aby ocenić wyniki w poszczególnych regionach lub czas obsługi wymiany walut. Poszczególne waluty mogą mieć różne godziny graniczne, cykle rozliczeniowe i wymogi regulacyjne, które bezpośrednio wpływają na przebieg procesu. Bez tego atrybutu pole „Kwota płatności” jest niejednoznaczne. Atrybut umożliwia przeliczenie różnych kwot na jedną walutę raportową na potrzeby globalnych dashboardów. Dlaczego to ważne Niezbędny do ujednolicania wartości finansowych i wykrywania różnic w procesach transgranicznych. Skąd pobrać Znajduje się w tabelach transakcji obok kwoty płatności. Przykłady USDEURGBPJPYCAD | |||
| Kwota płatności PaymentAmount | Wartość pieniężna transakcji płatniczej. | ||
| Opis Ten atrybut określa wartość przekazywanych środków. To podstawowa miara liczbowa pozwalająca ocenić wpływ nieefektywności procesu. Opóźnienie płatności na milion dolarów może mieć na przykład większe znaczenie niż opóźnienie płatności na dziesięć dolarów. W analizie pole to służy do agregowania wolumenów, obliczania łącznego zapotrzebowania na płynność i podziału płatności na przedziały kwotowe. Płatności o wysokiej wartości często podlegają innym workflow zatwierdzania niż płatności o niskiej wartości. Atrybut pozwala rozróżnić te ścieżki. Aby porównania były miarodajne, kwotę należy zestawiać z kodem waluty. Sumowanie kwot bez przeliczenia walut lub podziału według waluty może prowadzić do błędnych wniosków w raportach finansowych. Dlaczego to ważne Umożliwia analizę wpływu finansowego i podział transakcji na te o wysokiej i niskiej wartości. Skąd pobrać Znajduje się w szczegółach transakcji lub tabelach księgowań finansowych. Przykłady 150.0010000.5025.995000000.01 | |||
| Metoda płatności PaymentMethod | Instrument lub mechanizm użyty do realizacji płatności. | ||
| Opis Ten atrybut klasyfikuje płatności według sposobu realizacji, na przykład przelewu bankowego, ACH, karty kredytowej lub płatności natychmiastowej. Każda metoda zazwyczaj wiąże się z inną ścieżką procesu, czasem realizacji i kosztami. Podział danych według tego atrybutu pozwala porównać działanie różnych kanałów płatniczych. Na przykład przelewy bankowe mogą wymagać większej liczby ręcznych zatwierdzeń niż automatycznie przetwarzane paczki ACH. Znajomość struktury metod płatności pomaga planować zasoby i wykrywać zmiany zachowań klientów, takie jak przechodzenie od tradycyjnych czeków do cyfrowych płatności natychmiastowych. Dlaczego to ważne Pozwala rozróżnić warianty procesu, na przykład płatności natychmiastowe i przelewy bankowe, które podlegają różnym umowom SLA. Skąd pobrać Znajduje się w szczegółach zlecenia płatniczego. Przykłady Przelew bankowyACHKarta kredytowaPrzelew SEPAPłatność w czasie rzeczywistym | |||
| Termin płatności PaymentDueDate | Data, do której płatność powinna lub musi zostać rozliczona. | ||
| Opis Ten atrybut określa termin realizacji płatności. Pozwala mierzyć „odsetek płatności zrealizowanych w terminie” i sprawdzać, czy dotrzymano umów SLA. Porównanie rzeczywistego czasu zakończenia z terminem płatności daje jasną miarę skuteczności procesu. Płatności zrealizowane po terminie uznaje się za opóźnione, co może wiązać się z karami lub pogorszeniem relacji biznesowych. Pole to ma szczególne znaczenie w procesach zobowiązań oraz umowach gwarantujących realizację usług, w których termin jest zobowiązaniem umownym. Dlaczego to ważne Niezbędny do obliczania zgodności z SLA i odsetka płatności zrealizowanych w terminie. Skąd pobrać Znajduje się w nagłówku faktury lub zleceniu płatniczym. Przykłady 2023-10-302023-11-012023-10-152023-12-312024-01-01 | |||
| Użytkownik przetwarzający płatność ProcessingUser | Identyfikator użytkownika lub agenta systemowego odpowiedzialnego za wykonanie działania. | ||
| Opis Ten atrybut wskazuje, kto lub co wykonało dany krok procesu płatniczego. Może to być pracownik przeprowadzający ręczną weryfikację albo konto systemowe wykonujące zautomatyzowane zadanie. Dane te są niezbędne do analizy wykorzystania zasobów i wąskich gardeł. Pozwalają odróżnić przetwarzanie automatyczne (Straight-Through Processing, STP) od ręcznej obsługi. Duży udział pracy wykonywanej przez użytkowników często wiąże się z wyższymi kosztami i dłuższym czasem realizacji. Na potrzeby zgodności pole to pomaga analizować rozdział obowiązków i sprawdzić, czy płatność zatwierdza inna osoba niż ta, która ją utworzyła. Dlaczego to ważne Umożliwia analizę poziomu automatyzacji (STP) i produktywności zasobów. Skąd pobrać Znajduje się w dziennikach audytowych lub kolumnach metadanych tabeli transakcji. Przykłady SystemAgent_01jdoeAPPROVER_GROUP_AAutoReconcilerAPI_User | |||
| Kanał płatności ProcessingChannel | Interfejs lub kanał, za pośrednictwem którego zainicjowano płatność. | ||
| Opis Ten atrybut wskazuje miejsce wprowadzenia zlecenia płatniczego, na przykład aplikację mobilną, portal internetowy, API lub przesłany plik. Dostarcza informacji o zachowaniach klientów i korzystaniu z kanałów. Analiza wyników procesu według kanału może ujawnić różnice techniczne. Na przykład płatności zainicjowane przez API mogą być przetwarzane natychmiast, podczas gdy pliki mogą oczekiwać na przetwarzanie w zaplanowanym oknie. Pozwala to lepiej zrozumieć doświadczenia użytkowników na różnych platformach. Atrybut przydaje się również do analizy przechodzenia od starszych kanałów, takich jak ręczne wprowadzanie danych lub faks, do kanałów cyfrowych. Wspiera to inicjatywy związane z transformacją cyfrową. Dlaczego to ważne Pomaga analizować zmiany wolumenu i różnice w wynikach między kanałami wejściowymi, na przykład aplikacją mobilną i stroną internetową. Skąd pobrać Znajduje się w nagłówku transakcji lub metadanych sesji. Przykłady Aplikacja mobilnaPortal internetowyPlik H2HAPITerminal POS | |||
| Nazwa beneficjenta BeneficiaryName | Nazwa podmiotu lub osoby otrzymującej płatność. | ||
| Opis Ten atrybut wskazuje odbiorcę płatności. W relacjach B2B jest nim dostawca, a w relacjach P2P osoba fizyczna. Określa, komu przekazywane są środki. Analiza płatności według beneficjenta może ujawnić na przykład częste płatności na rzecz podmiotów wysokiego ryzyka lub nadmierną koncentrację płatności u wybranych dostawców. Przydaje się również w analizie nadużyć, na przykład do wykrywania wielu niewielkich płatności kierowanych do jednego nieoczekiwanego odbiorcy. Często występują tu problemy z jakością danych, takie jak różnice w pisowni (np. „Inc.” i „Incorporated”). Aby prawidłowo agregować dane, często trzeba je oczyścić. Dlaczego to ważne Przydatny do analizy dostawców, wykrywania nadużyć i oceny ryzyka. Skąd pobrać Znajduje się w sekcji danych beneficjenta zlecenia płatniczego. Przykłady Acme CorpGlobal Services LtdJohn SmithAzure Cloud ServicesOrgan podatkowy | |||
| Ocena ryzyka RiskScore | Wartość liczbowa określająca prawdopodobieństwo nadużycia lub ryzyka związanego ze zgodnością. | ||
| Opis Ten atrybut to wartość generowana przez silniki wykrywania nadużyć lub modele ryzyka. Wyższa ocena zazwyczaj oznacza większe prawdopodobieństwo, że transakcja jest nieuczciwa lub obarczona wysokim ryzykiem. W analizie procesu ocena pomaga wyjaśnić, dlaczego niektóre płatności przechodzą przez długie pętle weryfikacji. Płatności z wysoką oceną ryzyka często wymagają ręcznej interwencji, co wydłuża czas realizacji. Zestawienie ocen ryzyka z końcowymi wynikami (zatwierdzenie lub odrzucenie) pomaga dostosować skuteczność reguł oceny ryzyka. Nie każdy system generuje ocenę liczbową. Niektóre udostępniają jedynie flagę statusu. W nowoczesnych bramkach płatniczych ocena liczbowa jest jednak standardową miarą wykorzystywaną przy podejmowaniu decyzji. Dlaczego to ważne Pomaga wyjaśnić odstępstwa od standardowego przebiegu procesu, takie jak ręczne weryfikacje i wstrzymania związane z kontrolą nadużyć. Skąd pobrać Dane wyjściowe z systemu wykrywania nadużyć lub silnika oceny ryzyka. Przykłady 08512.5994 | |||
Działania w procesie obsługi płatności
| Działanie | Opis | ||
|---|---|---|---|
| Płatność autoryzowana | Potwierdzenie finansowe, że środki zostały zarezerwowane lub są dostępne na potrzeby transakcji. Zwykle wiąże się z komunikacją z systemem bankowym, wydawcą karty lub linią kredytową. | ||
| Dlaczego to ważne Potwierdzenie autoryzacji jest ważnym punktem kontroli przed faktycznym przekazaniem środków. Skąd pobrać Informacje można znaleźć w dziennikach odpowiedzi bramki płatniczej lub tabelach autoryzacji systemu bankowego. Rejestrowanie Wyodrębnij znacznik czasu pozytywnej odpowiedzi autoryzacyjnej. Typ zdarzenia explicit | |||
| Płatność nieudana | Końcowy status oznaczający, że płatności nie udało się zrealizować z powodu nieodwracalnego problemu technicznego lub finansowego. Oznacza definitywny koniec danej instancji procesu. | ||
| Dlaczego to ważne To ważny wskaźnik niezawodności. Analiza powtarzających się przyczyn pomaga ograniczyć liczbę porzuconych transakcji. Skąd pobrać Zdarzenie można odczytać z końcowych kodów niepowodzenia lub dzienników błędów krytycznych. Rejestrowanie Wykryj transakcje, które osiągnęły końcowy status niepowodzenia. Typ zdarzenia explicit | |||
| Płatność rozliczona | Pomyślne zakończenie transferu środków, które zostają zaksięgowane na rachunku odbiorcy. To podstawowy końcowy status oznaczający pomyślną realizację transakcji płatniczej. | ||
| Dlaczego to ważne Zdarzenie służy do obliczania całkowitego czasu cyklu i jest podstawowym kryterium pomyślnej realizacji procesu. Skąd pobrać Zwykle wskazuje na nie konkretny status rozliczenia, raport potwierdzający lub zapis w księdze głównej. Rejestrowanie Wyodrębnij datę i godzinę przetworzenia potwierdzenia rozliczenia. Typ zdarzenia explicit | |||
| Płatność utworzona | Utworzenie rekordu transakcji płatniczej w systemie. Zdarzenie zapisuje znacznik czasu pierwszego zarejestrowania zlecenia płatności, niezależnie od tego, czy użytkownik wprowadził je ręcznie, czy utworzono je za pomocą API. | ||
| Dlaczego to ważne Wyznacza początek całego cyklu obsługi płatności i stanowi punkt odniesienia do analizy wolumenu. Skąd pobrać Zwykle jest to znacznik czasu utworzenia rekordu w głównej tabeli transakcji albo wpis dotyczący nowego rekordu w dedykowanym dzienniku audytowym. Rejestrowanie Wybierz najwcześniejszy znacznik czasu powiązany z Payment Transaction ID. Typ zdarzenia explicit | |||
| Płatność zaakceptowana | Wewnętrzny etap, na którym upoważniony użytkownik lub reguła systemowa zezwala na dalszą obsługę płatności. Nie jest to zewnętrzna autoryzacja finansowa, lecz wewnętrzna zgoda organizacji. | ||
| Dlaczego to ważne Częste źródło wąskich gardeł ze względu na ręczny workflow i czas oczekiwania na działanie człowieka. Skąd pobrać Zdarzenie jest rejestrowane w dziennikach akceptacji workflow lub przy ustawieniu flagi akceptacji na wartość true. Rejestrowanie Zapisz znacznik czasu zatwierdzenia w bazie danych ostatniej czynności akceptacji. Typ zdarzenia explicit | |||
| Zlecenie płatnicze wysłane | Przekazanie sfinalizowanego pliku lub komunikatu płatniczego do zewnętrznej sieci płatniczej albo izby rozliczeniowej. Oznacza przekazanie obsługi z systemu wewnętrznego do podmiotu zewnętrznego. | ||
| Dlaczego to ważne To ważny punkt graniczny między czasem obsługi wewnętrznej a czasem rozliczenia zewnętrznego. Skąd pobrać Zdarzenie jest rejestrowane podczas generowania pliku, wysyłania wywołania API do sieci lub zmiany statusu na „Wysłano”. Rejestrowanie Ustal znacznik czasu wychodzącego wywołania API lub zdarzenia przesłania pliku. Typ zdarzenia explicit | |||
| Błąd płatności usunięty | Oznacza poprawienie wcześniej wykrytego problemu, dzięki czemu płatność może wrócić do standardowego przebiegu. Zwykle wymaga to ręcznej interwencji lub automatycznej ponownej próby. | ||
| Dlaczego to ważne To zdarzenie jest niezbędne do pomiaru czasu i nakładu pracy potrzebnych do obsługi wyjątków płatniczych. Skąd pobrać Zdarzenie można wywnioskować, gdy transakcja przechodzi ze stanu błędu z powrotem do stanu przetwarzania lub gotowości. Rejestrowanie Wykryj przejścia ze statusów błędu do prawidłowych statusów przetwarzania. Typ zdarzenia inferred | |||
| Płatność anulowana | Celowe zakończenie płatności przez użytkownika lub administratora przed jej rozliczeniem. W efekcie transakcja zostaje unieważniona. | ||
| Dlaczego to ważne Rozróżnienie anulowania od niepowodzenia pomaga odróżnić działania użytkowników od błędów systemu. Skąd pobrać Zdarzenie jest jawnie rejestrowane po wykonaniu polecenia anulowania lub zmianie statusu na „Unieważniono”. Rejestrowanie Zapisz znacznik czasu polecenia anulowania. Typ zdarzenia explicit | |||
| Płatność odrzucona | Zdarzenie oznaczające, że wewnętrzna osoba akceptująca lub zewnętrzny podmiot kontrolujący odrzucił zlecenie płatności. Bieżący przebieg zostaje zatrzymany, a osoba inicjująca może otrzymać powiadomienie. | ||
| Dlaczego to ważne To zdarzenie pomaga analizować przyczyny odrzuceń i ograniczać zbędne zakłócenia w obsłudze płatności. Skąd pobrać Zdarzenie jest jawnie rejestrowane w historii workflow lub wnioskowane na podstawie końcowej zmiany statusu, takiej jak „Odrzucono” lub „Odmówiono”. Rejestrowanie Zarejestruj konkretną czynność, podczas której użytkownik lub system generuje zdarzenie odrzucenia. Typ zdarzenia explicit | |||
| Płatność potwierdzona | Otrzymanie technicznego potwierdzenia z zewnętrznej sieci, że zlecenie zostało odebrane i ma prawidłowy format. Oznacza to, że płatność znajduje się już w zewnętrznym systemie obsługi. | ||
| Dlaczego to ważne Potwierdza, że przekazanie zlecenia do sieci zakończyło się powodzeniem, a transakcja oczekuje na rozliczenie. Skąd pobrać Zdarzenie można odczytać z przychodzących komunikatów potwierdzających (ACK) lub webhooków dostawcy. Rejestrowanie Zapisz czas otrzymania komunikatu potwierdzającego z systemu zewnętrznego. Typ zdarzenia explicit | |||
| Płatność uzgodniona | Proces księgowy polegający na dopasowaniu rekordu płatności z systemu do wyciągu bankowego lub ksiąg zewnętrznych. Dzięki temu można sprawdzić, czy dane w systemie odpowiadają rzeczywistym transakcjom. | ||
| Dlaczego to ważne Oznacza administracyjne zamknięcie transakcji i potwierdzenie rzetelności danych finansowych. Skąd pobrać Zdarzenie można znaleźć w modułach uzgadniania lub wywnioskować z przypisania transakcji identyfikatora dopasowania. Rejestrowanie Powiąż transakcję ze znacznikiem czasu w tabeli uzgodnień. Typ zdarzenia calculated | |||
| Płatność zweryfikowana | Zakończenie automatycznych kontroli zlecenia płatniczego, takich jak sprawdzenie składni formatu, poprawności numeru rachunku i zgodności z wymogami. Ten etap potwierdza poprawność danych przed przekazaniem płatności do akceptacji lub realizacji. | ||
| Dlaczego to ważne Długi czas trwania tego etapu może wskazywać na powolne działanie zewnętrznych usług walidacyjnych lub złożone reguły zgodności. Skąd pobrać Zwykle zdarzenie jest rejestrowane przy zmianie statusu z „Szkic” na „Zweryfikowano” albo wnioskowane na podstawie wpisu o pomyślnej walidacji. Rejestrowanie Wyszukaj zmiany statusu potwierdzające pomyślną walidację lub konkretne wpisy w dzienniku systemu kontroli zgodności. Typ zdarzenia inferred | |||
| Płatność zwrócona | Zdarzenie występuje, gdy rozliczona płatność zostaje cofnięta, a środki wracają do płatnika. Zwykle następuje już po nominalnym zakończeniu głównego procesu. | ||
| Dlaczego to ważne Odsetek zwrotów jest ważnym wskaźnikiem jakości usługi lub produktu. Skąd pobrać Zdarzenie można odczytać z powiązanej transakcji zwrotu lub zmiany statusu wskazującej cofnięcie płatności. Rejestrowanie Wykryj zdarzenia zwrotu powiązane z pierwotnym identyfikatorem płatności. Typ zdarzenia explicit | |||
| Wykryto błąd płatności | System lub zewnętrzny walidator wykrył problem z płatnością, na przykład brak wystarczających środków lub nieprawidłowe dane. To zdarzenie rozpoczyna obsługę wyjątku. | ||
| Dlaczego to ważne To zdarzenie jest niezbędne do obliczania odsetka ponownie wykonywanej pracy i wykrywania problemów z jakością danych wprowadzanych na wcześniejszych etapach. Skąd pobrać Zdarzenie można odczytać z dzienników błędów, tabel wyjątków lub kodów statusu wskazujących niepowodzenie albo wstrzymanie. Rejestrowanie Wyszukaj kody błędów lub zmiany statusu oznaczające, że transakcja wymaga poprawy. 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?
Pobierz ogólny szablon lub wybierz instrukcję ekstrakcji dla konkretnego systemu, aby sprawdzić, jak pobrać dane z używanego środowiska.
Ogranicz utratę przychodów związanych z płatnościami
Pełny wgląd w każdą transakcję i mniej błędów
Karta kredytowa nie jest wymagana • Konfiguracja w 5 minut