Szablon danych dotyczących obsługi płatności

Fiserv
Szablon danych dotyczących obsługi płatności

Szablon danych dotyczących obsługi płatności

Ten szablon pomaga uporządkować dane z Fiserv w formacie odpowiednim do process mining i analizy. Zawiera niezbędne atrybuty i działania, które pozwalają prześledzić cykle rozliczeń i uzgadniania. Postępując zgodnie z tym przewodnikiem, można przygotować dziennik zdarzeń pokazujący nieefektywności i zagrożenia dla zgodności w operacjach finansowych.
  • Zalecane atrybuty do analizy płatności
  • Najważniejsze etapy procesu do monitorowania
  • Wskazówki techniczne dotyczące pobierania danych z Fiserv
Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Atrybuty obsługi płatności

Te zalecane pola danych dostarczają kontekstu potrzebnego do analizy całego cyklu obsługi płatności na podstawie dziennika zdarzeń.
5 Wymagane 9 Zalecane 5 Opcjonalne
Nazwa Opis
Identyfikator transakcji płatniczej
PaymentTransactionId
Unikalny identyfikator konkretnej instrukcji płatniczej lub przypadku transakcji.
Opis

Ten atrybut jest głównym kluczem łączącym wszystkie działania w ramach cyklu życia pojedynczej płatności. Pozwala prześledzić jej przebieg od początkowego żądania przez walidację i akceptację aż po rozliczenie lub anulowanie.

W środowiskach Fiserv jest to zwykle klucz główny w tabelach historii transakcji. Umożliwia odtworzenie przepływu procesu i prawidłowe powiązanie zdarzeń, które wystąpiły w różnym czasie, na przykład rozliczenia następującego kilka dni po autoryzacji, z tym samym obiektem biznesowym.

Dlaczego to ważne

To podstawowy identyfikator przypadku, potrzebny do grupowania zdarzeń w instancje procesu.

Skąd pobrać

Informacje o tabelach transakcji lub nagłówków płatności można znaleźć w dokumentacji Fiserv.

Przykłady
TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
Nazwa działania
ActivityName
Zdarzenie lub zmiana statusu, które wystąpiły w procesie płatności.
Opis

Ten atrybut opisuje wykonany krok, na przykład „Utworzono żądanie płatności” lub „Rozliczono płatność”. Określa węzły na mapie procesu i pomaga zrozumieć kolejność operacji.

Analiza poszczególnych działań pozwala zwizualizować workflow, wykryć pominięte kroki i znaleźć ścieżki niezgodne z wymaganiami, na których pominięto obowiązkową walidację lub akceptację.

Dlaczego to ważne

Określa zdarzenia składające się na oś czasu procesu.

Skąd pobrać

Dziennik historii transakcji lub tabele audytowe zmian statusu.

Przykłady
Utworzenie zlecenia płatnościAutoryzacja płatnościWykrycie błędu płatnościPłatność rozliczonaPłatność anulowana
Znacznik czasu zdarzenia
EventTimestamp
Dokładna data i godzina wystąpienia działania.
Opis

Ten atrybut zapisuje dokładny moment wystąpienia zdarzenia. Stanowi podstawę analiz czasowych, w tym czasu cyklu, czasu realizacji i identyfikacji wąskich gardeł.

W dashboardach dane te służą do obliczania czasu między krokami, na przykład od „Utworzono żądanie płatności” do „Autoryzowano płatność”. Precyzyjne znaczniki czasu są potrzebne do prawidłowego uporządkowania zdarzeń następujących w krótkich odstępach.

Dlaczego to ważne

Pozwala uporządkować zdarzenia i obliczyć czas trwania etapów procesu.

Skąd pobrać

Logi audytowe lub kolumny ze znacznikami czasu aktualizacji transakcji.

Przykłady
2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
Data ostatniej aktualizacji danych
LastDataUpdate
Znacznik czasu ostatniej ekstrakcji lub odświeżenia rekordu.
Opis

Informuje, jak aktualne są dane używane w analizie. Pozwala ocenić, czy dashboardy pokazują bieżące operacje, czy dane historyczne.

Dzięki temu użytkownicy mogą ocenić wiarygodność prezentowanych wskaźników i uniknąć decyzji opartych na nieaktualnych danych, zwłaszcza podczas monitorowania zgodności z godzinami granicznymi lub aktywnych wąskich gardeł.

Dlaczego to ważne

Pozwala sprawdzić aktualność i wiarygodność danych.

Skąd pobrać

Czas systemowy w chwili wykonania ETL.

Przykłady
2023-10-27T12:00:00Z2023-10-28T06:00:00Z
System źródłowy
SourceSystem
Nazwa systemu, z którego pochodzą dane.
Opis

Wskazuje konkretny moduł Fiserv lub system zewnętrzny, który wygenerował zdarzenie. Jest to szczególnie przydatne w złożonym krajobrazie systemów, gdy płatność może zostać zainicjowana w kanale front-end, a rozliczona w podstawowym systemie bankowym.

Analitycy mogą filtrować widok procesu według systemu źródłowego i kierować analizę na konkretne środowiska techniczne lub punkty integracji.

Dlaczego to ważne

Zapewnia kontekst techniczny i informacje o pochodzeniu danych.

Skąd pobrać

Wartość ustawiana na stałe podczas ekstrakcji lub pobierana z metadanych systemu.

Przykłady
Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
Kod błędu
ErrorCode
Kod generowany w przypadku niepowodzenia walidacji płatności.
Opis

Zapisuje techniczny lub biznesowy kod błędu powiązany ze zdarzeniami „Wykryto błąd płatności”. Atrybut ten stanowi podstawę narzędzia do śledzenia błędów walidacji i poprawek.

Zestawienie częstotliwości poszczególnych kodów błędów pomaga wskazać systemowe problemy z jakością danych, na przykład „Nieprawidłowy numer rozliczeniowy”, i wprowadzić odpowiednie poprawki w logice walidacji lub szkoleniach użytkowników.

Dlaczego to ważne

Pomaga ustalić przyczyny konieczności ponownego wykonania pracy.

Skąd pobrać

Logi błędów lub szczegóły statusu transakcji.

Przykłady
E-101INV_ACCNSF_ERRAUTH_FAIL
Kod waluty
CurrencyCode
Kod waluty ISO dla kwoty płatności.
Opis

Określa walutę płatności, na przykład USD lub EUR. Atrybut ten jest potrzebny w dashboardzie trendów dotyczących walut i metod płatności. Pozwala monitorować ekspozycję na różne waluty.

Służy również do przeliczania kwot na potrzeby raportowania globalnego i zapobiega błędnemu oznaczaniu jako duplikatów transakcji o tej samej wartości liczbowej, ale w różnych walutach.

Dlaczego to ważne

Potrzebne do analizy płatności w wielu walutach.

Skąd pobrać

Tabela nagłówków transakcji, kolumna Currency.

Przykłady
USDEURGBPCADJPY
Kwota płatności
PaymentAmount
Wartość pieniężna transakcji płatniczej.
Opis

Ten atrybut określa wartość finansową płatności. Umożliwia podział analizy na płatności o dużej wartości i rutynowe transakcje o niższej wartości.

Jest niezbędny w widoku wykrywania duplikatów płatności. Identyczne kwoty zestawione z danymi płatnika i odbiorcy mogą wskazywać na błąd. Atrybut wspiera też analizę uprawnień do akceptacji, ponieważ wyższe kwoty często uruchamiają inne ścieżki workflow.

Dlaczego to ważne

Przydatne w analizie ryzyka finansowego i wykrywaniu duplikatów.

Skąd pobrać

Tabela nagłówków transakcji, kolumna Amount.

Przykłady
150.0025000.5010.991000000.00
Metoda płatności
PaymentMethod
Sposób realizacji płatności, na przykład Wire lub ACH.
Opis

Klasyfikuje transakcję według wykorzystywanego kanału rozliczeniowego. Atrybut ten jest podstawą analizy czasu cyklu autoryzacji, ponieważ poszczególne metody mają różne standardowe procedury operacyjne i umowy SLA.

Analiza wariantów procesu według metody płatności pomaga ustalić, czy opóźnienia dotyczą konkretnego kanału, na przykład przelewów międzynarodowych, czy całej organizacji.

Dlaczego to ważne

Dzieli przepływy procesu według wykorzystywanej infrastruktury.

Skąd pobrać

Kolumna z typem transakcji lub kodem instrumentu.

Przykłady
Przelew WireACHCzekRTPPrzelew wewnętrzny
Numer rachunku odbiorcy
PayeeAccountNumber
Numer rachunku, na który przekazywane są środki.
Opis

Wskazuje rachunek docelowy. Podobnie jak rachunek płatnika, jest niezbędny w widoku wykrywania duplikatów płatności. Pozwala prawidłowo uwzględnić konkretne relacje z odbiorcami.

Podczas monitorowania zgodności z godzinami granicznymi dane odbiorcy pomagają ustalać priorytety dla strategicznych dostawców lub ważnych rozliczeń, których nie można pominąć.

Dlaczego to ważne

Niezbędne do wykrywania duplikatów i analizy odbiorców płatności.

Skąd pobrać

Szczegóły transakcji, kolumna Credit Account lub Beneficiary.

Przykłady
555000111222333444BEN-882-11
Numer rachunku płatnika
PayerAccountNumber
Numer rachunku, z którego pobierane są środki.
Opis

Wskazuje rachunek źródłowy płatności. Jest ważnym elementem widoku wykrywania duplikatów płatności. W połączeniu z danymi odbiorcy, kwotą i czasem tworzy unikalny zestaw danych, który pomaga wykryć przypadkowe podwójne płatności.

Umożliwia też analizę liczby płatności z poszczególnych rachunków źródłowych i wskazanie najbardziej aktywnych portfeli wewnętrznych.

Dlaczego to ważne

Niezbędne do wykrywania duplikatów i analizy nadużyć.

Skąd pobrać

Szczegóły transakcji, kolumna Debit Account.

Przykłady
123456789987654321ACC-001-992
Przetwarzanie bezpośrednie
IsStraightThroughProcessing
Flaga informująca, czy płatność nie wymagała ręcznej obsługi.
Opis

Obliczany atrybut logiczny, który przyjmuje wartość prawda, jeśli przypadek nie obejmuje zdarzeń „Wykryto błąd płatności”, „Rozwiązano błąd płatności” ani ręcznego kroku „Zatwierdzono płatność”, zależnie od przyjętej definicji. Bezpośrednio wspiera wskaźnik KPI odsetka płatności przetwarzanych bezpośrednio.

Pozwala podzielić proces na przepływy w pełni zautomatyzowane i wymagające udziału człowieka, co ułatwia ocenę potencjału automatyzacji.

Dlaczego to ważne

Podstawowy wskaźnik efektywności procesu i skuteczności automatyzacji.

Skąd pobrać

Obliczane podczas transformacji danych.

Przykłady
truefalse
Termin płatności
PaymentDueDate
Data, do której płatność musi zostać przetworzona.
Opis

Docelowa data realizacji płatności. Monitor zgodności z godzinami granicznymi przetwarzania wykorzystuje ją do oznaczania transakcji zagrożonych opóźnieniem.

Porównanie znacznika czasu „Płatność rozliczona” z tym atrybutem pozwala obliczyć wskaźniki terminowości i pomaga utrzymać zaufanie odbiorców płatności.

Dlaczego to ważne

Punkt odniesienia przy pomiarze realizacji SLA.

Skąd pobrać

Szczegóły instrukcji płatniczej.

Przykłady
2023-11-012023-11-15
Użytkownik przetwarzający
ProcessingUser
Identyfikator użytkownika lub agenta systemowego odpowiedzialnego za działanie.
Opis

Wskazuje, kto wykonał dane działanie: osoba zatwierdzająca czy bot automatyzujący pracę systemu. Dane te zasilają dashboardy efektywności rozwiązywania błędów oraz przepustowości akceptacji płatności.

Śledzenie użytkowników pomaga wykryć potrzeby szkoleniowe osób popełniających dużo błędów oraz znaleźć wąskie gardła, gdy konkretni akceptujący są przeciążeni wnioskami.

Dlaczego to ważne

Umożliwia analizę zasobów i identyfikację wąskich gardeł.

Skąd pobrać

Logi audytowe, kolumna User ID.

Przykłady
jdoeSYSTEM_BATCHmsmith_approverAPI_USER
Bank odbiorcy
BeneficiaryBank
Nazwa lub identyfikator banku odbierającego płatność.
Opis

Wskazuje instytucję finansową, która otrzymuje płatność. Przydaje się w analizie opóźnień rozliczeń, ponieważ poszczególne banki mogą różnić się szybkością przetwarzania lub mieć problemy z integracją.

Uzupełnia dashboard pokazujący różnicę między rozliczeniem a uzgodnieniem i pomaga ustalić, czy opóźnienia wynikają z czynników zewnętrznych, związanych z konkretnym bankiem, czy z przyczyn wewnętrznych.

Dlaczego to ważne

Analiza zależności od podmiotów zewnętrznych.

Skąd pobrać

Szczegóły transakcji, kolumna Bank ID lub Name.

Przykłady
ChaseBank of AmericaWells FargoCitibank
Jednostka biznesowa
BusinessUnit
Dział lub jednostka, która zainicjowała płatność.
Opis

Przypisuje płatność do jednostki organizacyjnej odpowiedzialnej za wydatek. Pomaga rozliczać koszty i ustalić, które części organizacji generują najwięcej ręcznych poprawek lub błędów.

Wspiera audyt zgodności ścieżki płatności, pozwalając sprawdzić, czy poszczególne jednostki przestrzegają właściwych dla nich wymogów regulacyjnych i kontroli wewnętrznych.

Dlaczego to ważne

Zapewnia kontekst organizacyjny potrzebny do oceny wyników.

Skąd pobrać

Mapowanie centrów kosztów lub kod działu.

Przykłady
Bankowość detalicznaFinansowanie przedsiębiorstwZarządzanie majątkiemOperacje
Ponowne wykonanie pracy
IsRework
Flaga informująca, czy dane działanie jest częścią pętli poprawek.
Opis

Flaga logiczna oznaczająca działania wykonane po wykryciu błędu, ale przed jego rozwiązaniem, lub powtórzone działania. Wspiera wskaźnik KPI odsetka poprawek po walidacji płatności.

Analitycy mogą filtrować mapę procesu, aby wyświetlić tylko standardową ścieżkę albo skupić się na ścieżce poprawek i lepiej zrozumieć przyczyny niepowodzeń.

Dlaczego to ważne

Pozwala oddzielić pracę przynoszącą wartość od pracy związanej z poprawkami.

Skąd pobrać

Obliczane na podstawie pętli procesu.

Przykłady
truefalse
Poziom akceptacji
ApprovalLevel
Poziom hierarchii wymagany lub zastosowany do autoryzacji płatności.
Opis

Określa staż lub poziom uprawnień związany z działaniem „Zatwierdzono płatność”. Dashboard przepustowości akceptacji płatności pozwala sprawdzić, czy osoby zatwierdzające na wyższych szczeblach nie stają się wąskim gardłem.

Analiza rozkładu płatności według poziomów, na przykład poziomu 1 i 3, pomaga usprawnić zasady delegowania uprawnień.

Dlaczego to ważne

Pozwala analizować wąskie gardła w akceptacji według szczebla hierarchii.

Skąd pobrać

Tabele ról użytkowników lub workflow akceptacji.

Przykłady
Poziom 1MenedżerDyrektorCFO
Przekroczono godzinę graniczną
IsCutoffMissed
Flaga informująca, czy płatność wysłano po dziennej godzinie granicznej banku.
Opis

Obliczana wartość logiczna, która porównuje godzinę zdarzenia „Wysłano instrukcję płatniczą” z dzienną godziną graniczną dla danej waluty i metody płatności. Wspiera wskaźnik KPI terminowości względem godziny granicznej.

Wykrycie przekroczonych godzin granicznych pomaga ustalić przyczyny opóźnień, takie jak późne rozpoczęcie procesu lub powolne przetwarzanie wewnętrzne.

Dlaczego to ważne

Ważne dla zgodności operacyjnej i zarządzania płynnością.

Skąd pobrać

Obliczane przez porównanie EventTimestamp z tabelą Cutoff Reference.

Przykłady
truefalse
Wymagane Zalecane Opcjonalne

Działania w procesie obsługi płatności

Uwzględnij te etapy i kamienie milowe w dzienniku zdarzeń, aby dokładnie odkrywać i optymalizować workflow płatności.
5 Zalecane 8 Opcjonalne
Działanie Opis
Akceptacja płatności
Ręczna lub automatyczna decyzja o dopuszczeniu płatności do realizacji na podstawie limitów uprawnień. Zdarzenie jest rejestrowane, gdy uprawniony użytkownik lub reguła systemowa zmienia flagę akceptacji.
Dlaczego to ważne

Ważne dla analizy 'Authorization Cycle Time Analysis'. Opóźnienia na tym etapie wskazują na wąskie gardła w procesie akceptacji przez pracowników.

Skąd pobrać

Dzienniki audytowe pokazujące działanie użytkownika, które zmienia status z 'Pending Approval' na 'Approved'.

Rejestrowanie

Rejestrowane po zatwierdzeniu płatności

Typ zdarzenia explicit
Instrukcja płatnicza wysłana
Wysłanie pliku płatniczego (np. paczki ACH lub komunikatu Wire) do sieci zewnętrznej albo izby rozliczeniowej. To ważny punkt przekazania.
Dlaczego to ważne

Niezbędne dla monitora zgodności z godzinami granicznymi przetwarzania. Pozwala sprawdzić, czy organizacja dotrzymuje dziennych godzin granicznych banków.

Skąd pobrać

Logi przetwarzania paczek lub znaczniki czasu generowania plików. Zdarzenia są często rejestrowane jako „Utworzono paczkę” lub „Wysłano plik”.

Rejestrowanie

Rejestrowane po wygenerowaniu pliku paczki

Typ zdarzenia explicit
Płatność rozliczona
Przekazanie środków zostało zakończone, a transakcję zaksięgowano w księdze głównej. Z perspektywy banku oznacza to finansowe zakończenie transakcji.
Dlaczego to ważne

Główny punkt końcowy wskaźnika „Odsetek płatności przetwarzanych bezpośrednio”. Oznacza, że środki faktycznie zmieniły właściciela.

Skąd pobrać

Status transakcji „Zaksięgowano” lub znacznik czasu „Data księgowania” w księdze.

Rejestrowanie

Rejestrowane po zaksięgowaniu w księdze głównej

Typ zdarzenia explicit
Płatność uzgodniona
Wewnętrzne dopasowanie transakcji do wyciągów bankowych lub plików rozliczeniowych. Ten etap zamyka cykl księgowy.
Dlaczego to ważne

Wymagane do obliczenia różnicy między rozliczeniem a uzgodnieniem. Pozwala prawidłowo zamknąć księgi finansowe.

Skąd pobrać

Logi modułu uzgodnień, w których status zmienia się na „Dopasowano” lub „Uzgodniono”.

Rejestrowanie

Rejestrowane po dopasowaniu w ramach uzgodnienia

Typ zdarzenia explicit
Utworzenie zlecenia płatności
Pierwsze wprowadzenie dyspozycji płatniczej do systemu Fiserv. Zdarzenie jest rejestrowane, gdy użytkownik lub system zewnętrzny inicjuje transakcję przez API lub interfejs.
Dlaczego to ważne

Wyznacza początek osi czasu procesu. Jest niezbędne do obliczenia całkowitego czasu realizacji i wykrycia wąskich gardeł na etapie przyjmowania zleceń.

Skąd pobrać

Znacznik czasu utworzenia rekordu w tabeli historii transakcji. Należy znaleźć najwcześniejszy rekord z danym Payment Transaction ID.

Rejestrowanie

Rejestrowane po dodaniu rekordu transakcji

Typ zdarzenia explicit
Autoryzacja płatności
Końcowe wewnętrzne potwierdzenie dostępności środków i dopuszczenia transakcji do realizacji. Może nastąpić równocześnie z akceptacją lub jako osobna kontrola systemowa.
Dlaczego to ważne

Pozwala odróżnić akceptację menedżerską od autoryzacji na poziomie systemu. Ważne dla dashboardu „Przepustowość akceptacji płatności”.

Skąd pobrać

Zmiana statusu na „Autoryzowano” lub „Gotowe do zaksięgowania”.

Rejestrowanie

Porównanie pola statusu przed zmianą i po niej

Typ zdarzenia inferred
Płatność anulowana
Zakończenie przepływu płatności przed rozliczeniem, zainicjowane przez użytkownika lub regułę systemową. Zatrzymuje dalsze przetwarzanie.
Dlaczego to ważne

Pozwala wykryć straty i porzuconą pracę. Wysoki odsetek anulowań po zatwierdzeniu może wskazywać na nieefektywność procesu.

Skąd pobrać

Zmiana statusu na „Anulowano”, „Unieważniono” lub „Zatrzymano”.

Rejestrowanie

Rejestrowane po zmianie statusu na „Anulowano”

Typ zdarzenia explicit
Płatność potwierdzona
Otrzymanie pozytywnego potwierdzenia (ACK) z sieci zewnętrznej lub bramki. Potwierdza ono, że kolejny podmiot prawidłowo otrzymał instrukcję.
Dlaczego to ważne

Pozwala sprawdzić, czy wysłanie instrukcji zakończyło się powodzeniem. Przerwy na tym etapie mogą wskazywać na problemy z łącznością sieciową lub formatem wymaganym przez system zewnętrzny.

Skąd pobrać

Logi przetwarzania plików przychodzących lub kody odpowiedzi API potwierdzające odbiór.

Rejestrowanie

Rejestrowane po otrzymaniu ACK

Typ zdarzenia explicit
Płatność zaplanowana
Zdarzenie występuje, gdy płatność została zatwierdzona, ale jej realizację odłożono do przyszłej daty. System umieszcza transakcję w kolejce i czeka na rozpoczęcie okna przetwarzania.
Dlaczego to ważne

Pozwala wyjaśnić przestoje w procesie. Pomaga odróżnić opóźnienie spowodowane wąskim gardłem od celowego oczekiwania na termin płatności.

Skąd pobrać

Porównanie „Daty wprowadzenia” z „Datą realizacji”. Jeśli data realizacji przypada w przyszłości, ten stan jest aktywny.

Rejestrowanie

Wyznaczane przez porównanie pola X z polem Y

Typ zdarzenia calculated
Powiadomienie o płatności wysłane
System wysyła płatnikowi lub odbiorcy powiadomienie (e-mail/SMS) z potwierdzeniem transakcji. Dzięki temu klient ma lepszy wgląd w jej przebieg.
Dlaczego to ważne

Wspiera analizę szybkości i terminowości powiadomień. Długie przerwy po rozliczeniu płatności mogą osłabiać zaufanie klientów.

Skąd pobrać

Logi komunikacji lub tabele historii kontaktów z klientem powiązane z identyfikatorem transakcji.

Rejestrowanie

Rejestrowane po wysłaniu e-maila/SMS-a

Typ zdarzenia explicit
Rozwiązanie błędu płatności
Oznacza skorygowanie transakcji, w której wcześniej wystąpił błąd. Zdarzenie wnioskuje się, gdy status transakcji zmienia się z błędu na status przetwarzania lub prawidłowy.
Dlaczego to ważne

Niezbędne do obliczenia wskaźnika 'Mean Time to Resolve Payment Errors'. Pomaga mierzyć sprawność zespołu operacyjnego.

Skąd pobrać

Wnioskowane, gdy status transakcji zmienia się z kodu błędu na standardowy kod przetwarzania.

Rejestrowanie

Porównanie pola statusu przed zmianą i po niej

Typ zdarzenia inferred
Walidacja danych płatności
System sprawdza numery kont i rozliczeniowe oraz zgodność formatu. Zdarzenie zwykle wnioskuje się na podstawie przejścia transakcji ze statusu otrzymanej do oczekującej lub zaakceptowanej bez błędu.
Dlaczego to ważne

Oznacza przejście pierwszej automatycznej kontroli. Niepowodzenie na tym etapie wskazuje na problemy z jakością danych, a nie z płynnością lub akceptacją.

Skąd pobrać

Wnioskowane na podstawie zmiany statusu z 'Received' na 'Pending' lub 'Ready' w krótkim czasie.

Rejestrowanie

Porównanie pola statusu przed zmianą i po niej

Typ zdarzenia inferred
Wykrycie błędu płatności
Rejestruje moment oznaczenia transakcji statusem błędu lub kodem wyjątku. Zdarzenie występuje, gdy reguły walidacji nie zostaną spełnione lub kontrola zewnętrzna zwróci wynik negatywny.
Dlaczego to ważne

Niezbędne dla dashboardu 'Validation Error and Rework Tracker'. Duża liczba takich zdarzeń wskazuje na problemy z jakością danych na wcześniejszych etapach.

Skąd pobrać

Pole statusu transakcji zmienia się na kod wyjątku, np. 'Invalid', 'Hold' lub 'Error'.

Rejestrowanie

Rejestrowane po zmianie statusu na Error

Typ zdarzenia explicit
Zalecane Opcjonalne

Przewodniki dotyczące pobierania danych

Jak pobrać dane z Fiserv

Gotowi do rozpoczęcia?

Zacznij usprawniać workflow finansowe, stosując ten szablon w środowisku Fiserv. Dzięki wskazówkom można przygotować dane potrzebne do poprawy przepływów pieniężnych i zgodności operacyjnej.

Usprawnij obsługę płatności i osiągnij dziś 98% STP

Ogranicz opóźnienia w uzgadnianiu i lepiej kontroluj workflow Fiserv.

Rozpocznij okres próbny

Nie trzeba podawać danych karty. Konfiguracja zajmuje kilka minut.