Szablon danych dotyczących obsługi płatności
Szablon danych dotyczących obsługi płatności
- Zalecane atrybuty do analizy płatności
- Najważniejsze etapy procesu do monitorowania
- Wskazówki techniczne dotyczące pobierania danych z Fiserv
Atrybuty obsługi płatności
| 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
|
|||
Działania w procesie obsługi płatności
| 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
|
|||
Przewodniki dotyczące pobierania danych
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.
Nie trzeba podawać danych karty. Konfiguracja zajmuje kilka minut.