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

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

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

Ten szablon pomaga przygotować dane dotyczące obsługi płatności do analizy. Zawiera listę atrybutów do zebrania, najważniejszych aktywności do śledzenia oraz praktyczne wskazówki dotyczące pobierania informacji z systemu. Zastosowanie tych zaleceń zapewnia solidną podstawę do wykrywania nieefektywności i usprawniania operacji finansowych.
  • Zalecane atrybuty do zebrania
  • Najważniejsze aktywności do śledzenia
  • Wskazówki dotyczące pobierania danych z ACI Worldwide
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

Oto zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie analizować obsługę płatności.
3 Wymagane 9 Zalecane 7 Opcjonalne
Nazwa Opis
Identyfikator transakcji płatniczej
PaymentTransactionId
Unikalny identyfikator konkretnej dyspozycji płatniczej w systemie ACI.
Opis

Ten atrybut jest głównym kluczem analizy process mining i łączy wszystkie zdarzenia dotyczące pojedynczego żądania płatniczego. W systemach ACI Worldwide, takich jak MTS lub UPP, odpowiada unikalnemu numerowi referencyjnemu przypisanemu transakcji podczas jej wprowadzania. Umożliwia odtworzenie całej ścieżki płatności, od początkowego żądania przez walidację i zatwierdzenie aż po końcowe rozliczenie.

Dlaczego to ważne

To podstawowy identyfikator sprawy (Case ID), wymagany do grupowania pojedynczych zdarzeń w instancje procesu.

Skąd pobrać

Należy sprawdzić tabele nagłówków transakcji. Pole może mieć nazwę TRN_REF, REFERENCE_NUM lub UUID w głównym dzienniku transakcji.

Przykłady
TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981
Nazwa działania
ActivityName
Krok lub zmiana statusu, które wystąpiły w cyklu obsługi płatności.
Opis

Ten atrybut określa węzeł zdarzenia na mapie procesu, na przykład „Utworzono żądanie płatnicze” lub „Przekazano środki”. W systemach ACI jest zwykle wyprowadzany z kodów statusu, typów operacji w dzienniku audytowym lub zmian stanu workflow. Prawidłowe mapowanie stanów technicznych na zrozumiałe działania biznesowe jest niezbędne do czytelnej wizualizacji.

Dlaczego to ważne

Określa przebieg procesu i jest niezbędny do wizualizacji kolejności operacji.

Skąd pobrać

Na podstawie kodów statusu (np. 100=Utworzono, 200=Zatwierdzono) lub kolumn z działaniami w dzienniku audytowym.

Przykłady
Utworzono zlecenie płatniczeAutoryzowano płatnośćRozliczono płatnośćPłatność nie powiodła się
Znacznik czasu zdarzenia
EventTimestamp
Dokładna data i godzina wystąpienia działania.
Opis

Ten atrybut zapisuje dokładny moment wystąpienia zdarzenia w środowisku ACI. Służy do obliczania wszystkich miar czasu, w tym czasu cyklu, czasu zatwierdzania i przepustowości. Dla prawidłowego ustalenia kolejności szybko następujących po sobie kroków automatycznych zalecana jest wysoka precyzja, do milisekund.

Dlaczego to ważne

Niezbędny do ustalania kolejności zdarzeń i obliczania czasu trwania działań.

Skąd pobrać

Należy sprawdzić kolumny „Created Date” lub „Update Date” w historii transakcji albo tabelach audytowych.

Przykłady
2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z
Czy wystąpiły poprawki
IsRework
Flaga wskazująca, czy w ramach płatności powtarzały się działania.
Opis

Wartość logiczna obliczana podczas przetwarzania danych. Przyjmuje wartość true, jeśli działanie takie jak „Zweryfikowano szczegóły płatności” występuje więcej niż raz lub wykryto pętlę błędu. Na tej podstawie oblicza się KPI „Odsetek płatności wymagających poprawek”.

Dlaczego to ważne

Pozwala szybko wykryć nieefektywne sprawy bez tworzenia złożonych zapytań o proces.

Skąd pobrać

Obliczane w potoku danych przez sprawdzenie, czy w danej sprawie występują powtórzone działania.

Przykłady
truefalse
Dział
Department
Dział wewnętrzny odpowiedzialny za bieżące działanie.
Opis

Przypisuje EventUser lub kolejkę do większej jednostki organizacyjnej, na przykład „Operacje płatnicze”, „Zgodność” lub „Skarb”. Analiza wąskich gardeł według działania pozwala sprawdzić, które zespoły opóźniają proces.

Dlaczego to ważne

Zestawia wyniki według funkcji biznesowej.

Skąd pobrać

Na podstawie tabel użytkowników lub mapowania hierarchii organizacyjnej.

Przykłady
OperacjeComplianceSkarbWsparcie IT
Kanał przetwarzania
ProcessingChannel
Kanał, za pośrednictwem którego zainicjowano płatność.
Opis

Wskazuje sposób wprowadzenia płatności, na przykład przez aplikację mobilną, portal internetowy, API lub przesłanie pliku. Analiza wariantów procesu płatności pozwala sprawdzić, czy w którymś kanale częściej występują błędy lub opóźnienia.

Dlaczego to ważne

Umożliwia porównanie wyników według sposobu wprowadzenia płatności.

Skąd pobrać

Nagłówek transakcji, często kolumny o nazwach CHANNEL, SOURCE_TYPE lub INPUT_METHOD.

Przykłady
SWIFTBankowość internetowaAplikacja mobilnaPrzesłanie pliku
Kod błędu
ErrorCode
Kod generowany, gdy płatność się nie powiedzie lub wymaga naprawy.
Opis

Zapisuje konkretną przyczynę zdarzenia „Płatność nie powiodła się” lub „Wykryto błąd płatności”. Grupowanie według tego atrybutu w dashboardzie „Analiza nieudanych płatności i poprawek” pozwala ustalić najczęstsze przyczyny źródłowe niepowodzeń, na przykład „Niewystarczające środki” lub „Nieprawidłowy rachunek”.

Dlaczego to ważne

Niezbędny do analizy przyczyn źródłowych niepowodzeń procesu.

Skąd pobrać

Dzienniki błędów lub kolumny z przyczyną statusu, często REASON_CODE lub RETURN_CODE.

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

Określa wartość przekazywanych środków. To ważny kontekst przy analizie „Przepustowości płatności” i ustalaniu priorytetów dotyczących wąskich gardeł. Płatności na wysokie kwoty często przechodzą bardziej rygorystyczną ścieżkę zatwierdzania niż zautomatyzowane płatności na niższe kwoty. Można to sprawdzić w analizie wariantów.

Dlaczego to ważne

Umożliwia podział płatności według kwoty i obliczenie łącznej wartości przetworzonych płatności.

Skąd pobrać

Tabele szczegółów transakcji, zwykle pola takie jak AMT, TRANS_AMOUNT lub PRINCIPAL_AMOUNT.

Przykłady
1500.00250000.5050.001000000.00
Rodzaj płatności
PaymentType
Klasyfikacja instrumentu płatniczego.
Opis

Kategoryzuje płatności, na przykład jako przelew bankowy, ACH, SEPA lub RTGS. Poszczególne rodzaje płatności często podlegają różnym SLA i przebiegają według odmiennych ścieżek. Ten atrybut jest podstawowym wymiarem filtrowania dashboardu „Czas cyklu płatności od początku do końca”.

Dlaczego to ważne

Pozwala odróżnić szybkie płatności od płatności przetwarzanych w partiach.

Skąd pobrać

Nagłówek transakcji, pola takie jak PMT_TYPE, INSTRUMENT_TYPE lub SERVICE_ID.

Przykłady
Krajowy przelew bankowyMiędzynarodowy przelew bankowyPrzelew uznaniowy ACHPłatność natychmiastowa
Termin płatności
PaymentDueDate
Data, do której płatność musi zostać rozliczona, aby uznać ją za terminową.
Opis

Zapisuje uzgodnioną lub wskazaną datę realizacji. Porównanie tej daty z faktyczną datą rozliczenia pozwala obliczyć KPI „Odsetek płatności zrealizowanych w terminie” i zasila dashboard „Zgodność z terminem płatności”.

Dlaczego to ważne

Punkt odniesienia przy pomiarze zgodności z SLA i terminowości realizacji.

Skąd pobrać

Dyspozycje transakcji, zwykle pola VALUE_DATE, EXECUTION_DATE lub DUE_DATE.

Przykłady
2023-11-012023-11-05
Użytkownik wykonujący zdarzenie
EventUser
Identyfikator użytkownika lub agenta systemowego odpowiedzialnego za działanie.
Opis

Informuje, kto wykonał działanie: użytkownik (np. zatwierdzający) czy konto systemowe (np. przy automatycznym rozliczeniu). Ten atrybut jest niezbędny w analizie wąskich gardeł, która pozwala ustalić, czy konkretni użytkownicy lub kolejki są przeciążeni.

Dlaczego to ważne

Umożliwia analizę zasobów i audyt rozdziału obowiązków.

Skąd pobrać

Dzienniki audytowe lub kolumny „UpdatedBy” w tabelach transakcji.

Przykłady
SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS
Waluta płatności
PaymentCurrency
Kod waluty ISO dla kwoty płatności.
Opis

Określa walutę, w której wyrażono wartość PaymentAmount (np. USD, EUR, GBP). Jest niezbędny do ujednolicenia danych w dashboardach agregujących płatności z różnych regionów. Pomaga też analizować złożoność płatności transgranicznych.

Dlaczego to ważne

Niezbędny do prawidłowej interpretacji kwoty płatności.

Skąd pobrać

Tabele szczegółów transakcji, zwykle pola takie jak CCY, CURRENCY_CODE lub ISO_CODE.

Przykłady
USDEURGBPJPY
Czas cyklu zatwierdzania
ApprovalCycleTime
Czas spędzony na etapie zatwierdzania.
Opis

Oblicza czas od „Przekazano płatność do zatwierdzenia” do „Zatwierdzono płatność” lub jej odrzucenia. Ta miara zasila dashboard „Analiza czasu cyklu zatwierdzania płatności” i pokazuje opóźnienia na etapach wymagających decyzji człowieka.

Dlaczego to ważne

Pozwala wyodrębnić część procesu zależną od decyzji człowieka.

Skąd pobrać

Obliczenie: Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval).

Przykłady
4 godziny15 minut
Czy płatność była opóźniona
IsPaymentLate
Flaga wskazująca, czy płatność rozliczono po terminie.
Opis

Wartość logiczna porównująca faktyczną datę rozliczenia z PaymentDueDate. Służy do obliczania miar dashboardu „Zgodność z terminem płatności” i wykrywania naruszeń SLA.

Dlaczego to ważne

Ułatwia raportowanie zgodności.

Skąd pobrać

Obliczenie: SettlementDate > PaymentDueDate.

Przykłady
truefalse
Identyfikator uzgodnienia
ReconciliationId
Identyfikator łączący płatność z księgą główną lub rekordem uzgodnienia.
Opis

Ten identyfikator jest uzupełniany po wystąpieniu działania „Uzgodniono płatność”. Potwierdza zgodność płatności w silniku przetwarzania z zapisem w systemie księgowym. Brak identyfikatora przy rozliczonej płatności wskazuje na problem z uzgodnieniem.

Dlaczego to ważne

Niezbędny w dashboardzie „Sprawność uzgadniania płatności”.

Skąd pobrać

Tabele uzgodnień lub konkretne pola, takie jak RECON_REF lub GL_REF.

Przykłady
REC-9921GL-Entry-2023-11
Nazwa odbiorcy
BeneficiaryName
Nazwa podmiotu otrzymującego płatność.
Opis

Identyfikuje kontrahenta w transakcji. Analiza tego pola może pomóc wskazać dostawców lub klientów powiązanych z częstymi poprawkami albo opóźnieniami. Wspiera to analizę nieudanych płatności i poprawek.

Dlaczego to ważne

Wskazuje odbiorcę płatności i ułatwia analizę z perspektywy klienta.

Skąd pobrać

Pozycje szczegółów płatności, pola takie jak CREDITOR_NAME, BENE_NAME lub PAYEE.

Przykłady
Acme CorpGlobal Supplies LtdJohn Smith
Ostatnia aktualizacja danych
LastDataUpdate
Znacznik czasu ostatniego wyodrębnienia lub aktualizacji rekordu w modelu danych.
Opis

Informuje o aktualności danych użytych w analizie. Nie oznacza czasu zdarzenia w procesie, lecz techniczny czas wczytania danych. Dzięki temu analitycy wiedzą, czy pracują na danych bieżących, czy historycznych.

Dlaczego to ważne

Pozwala ocenić aktualność danych i wykryć nieaktualne dane w dashboardach.

Skąd pobrać

Czas systemowy w chwili uruchomienia skryptu ETL.

Przykłady
2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z
Region pochodzenia
OriginatingRegion
Region geograficzny, z którego pochodzi żądanie płatnicze.
Opis

Wskazuje fizyczną lub logiczną lokalizację osoby składającej żądanie. Analiza wariantów procesu płatności pozwala sprawdzić, czy w konkretnych regionach proces przebiega niestandardowo lub częściej kończy się odrzuceniem.

Dlaczego to ważne

Uzupełnia analizę wyników procesu o kontekst geograficzny.

Skąd pobrać

Nagłówek transakcji, często wartość wyprowadzana z kodu oddziału lub kraju.

Przykłady
Ameryka PółnocnaEMEAAPAC
System źródłowy
SourceSystem
Nazwa systemu, z którego pochodzą dane o zdarzeniu.
Opis

Wskazuje konkretną aplikację lub moduł w ekosystemie ACI Worldwide, na przykład ACI MTS lub ACI UPF, albo systemy zewnętrzne uczestniczące w przepływie. Jest to szczególnie ważne przy łączeniu danych z wielu ksiąg lub gdy płatność przechodzi przez zewnętrzne izby rozliczeniowe.

Dlaczego to ważne

Informuje, skąd wyodrębniono dane, co ułatwia analizę ich pochodzenia i diagnozowanie problemów.

Skąd pobrać

Wartość ustawiana na stałe podczas ekstrakcji lub pobierana z kolumny SystemID, jeśli istnieje wiele instancji.

Przykłady
ACI MTSACI UPPSAP GLSwift Gateway
Wymagane Zalecane Opcjonalne

Aktywności w procesie obsługi płatności

Oto najważniejsze etapy i kamienie milowe procesu, które warto rejestrować w dzienniku zdarzeń, aby prawidłowo odkryć przebieg obsługi płatności.
6 Zalecane 8 Opcjonalne
Działanie Opis
Autoryzowano płatność
Oznacza autoryzację płatności przez system po jej zatwierdzeniu przez człowieka. System sprawdza dostępność środków lub weryfikuje płatność pod kątem reguł przeciwdziałania oszustwom. Może to być jawny wpis w dzienniku albo zdarzenie wywnioskowane ze zmiany statusu wskazującej gotowość do realizacji.
Dlaczego to ważne

To ważny punkt kontrolny przed zleceniem przekazania środków. Opóźnienia na tym etapie mogą wskazywać na problemy z wydajnością systemu lub działaniem podsystemów kontroli zgodności i wykrywania oszustw.

Skąd pobrać

Należy sprawdzić, czy zdarzenie jest jawnie zapisane w dzienniku przetwarzania systemu lub dzienniku bezpieczeństwa. Można je też wywnioskować ze zmiany statusu z „Zatwierdzona” na „Autoryzowana do płatności”.

Rejestrowanie

Zdarzenie jest rejestrowane przez silnik płatniczy systemu po przejściu końcowych kontroli wewnętrznych.

Typ zdarzenia explicit
Przekazano środki
Oznacza otrzymanie od sieci płatniczej potwierdzenia, że środki zostały pomyślnie pobrane z rachunku płatnika. Zwykle informacja ta pochodzi z przychodzącego komunikatu o statusie z sieci.
Dlaczego to ważne

Potwierdza pomyślną realizację płatności przez sieć zewnętrzną. Rozpoczyna okres rozliczenia i stanowi ważną daną wejściową dla KPI „Średni czas rozliczenia płatności”.

Skąd pobrać

To jawne zdarzenie wywoływane przez przychodzący komunikat o zmianie statusu, na przykład MT103 z SWIFT lub potwierdzenie ACH, który aktualizuje rekord płatności.

Rejestrowanie

Zdarzenie jest rejestrowane po otrzymaniu zewnętrznego potwierdzenia z sieci rozliczeniowej.

Typ zdarzenia explicit
Rozliczono płatność
To końcowe potwierdzenie zakończenia procesu płatności i zaksięgowania środków na rachunku odbiorcy. Kończy transakcję i jest ważnym zdarzeniem oznaczającym pomyślne zakończenie całego cyklu płatności.
Dlaczego to ważne

To główne zdarzenie oznaczające pomyślne zakończenie procesu. Służy do obliczania całkowitego czasu realizacji i przepustowości oraz jest niezbędne w większości dashboardów monitorujących wyniki procesu od początku do końca.

Skąd pobrać

Zwykle jest to jawne zdarzenie rejestrowane po otrzymaniu z sieci końcowego potwierdzenia rozliczenia lub po aktualizacji księgi wewnętrznej odzwierciedlającej zakończenie transakcji.

Rejestrowanie

Rejestrowane po otrzymaniu końcowego pliku lub komunikatu rozliczeniowego. Status zmienia się wtedy na „Rozliczono”.

Typ zdarzenia explicit
Utworzono zlecenie płatnicze
To zdarzenie oznacza rozpoczęcie nowej transakcji płatniczej w systemie ACI Worldwide. Zwykle jest rejestrowane w chwili, gdy użytkownik lub system nadrzędny przesyła zlecenie płatnicze. Powstaje wtedy nowy rekord transakcji z unikalnym identyfikatorem.
Dlaczego to ważne

To główne zdarzenie rozpoczynające proces płatności. Analiza czasu od tej czynności do zakończenia procesu pozwala obliczyć całkowity czas realizacji, niezbędny do oceny ogólnej efektywności procesu.

Skąd pobrać

Zdarzenie jest prawdopodobnie jawnie rejestrowane w głównej tabeli transakcji lub dedykowanym dzienniku zdarzeń w ACI. Należy znaleźć znacznik czasu utworzenia powiązany z identyfikatorem transakcji płatniczej.

Rejestrowanie

Identyfikowane na podstawie rekordu utworzenia lub jawnego zdarzenia „Utworzenie” w dzienniku transakcji.

Typ zdarzenia explicit
Wykryto błąd płatności
Oznacza, że system wykrył problem na którymś etapie obsługi płatności, na przykład nieprawidłowe dane lub alert dotyczący zgodności. Zdarzenie to jest zwykle rejestrowane wprost wraz z kodem błędu.
Dlaczego to ważne

To działanie stanowi punkt wyjścia do analizy poprawek i obsługi wyjątków. Jest niezbędne w dashboardach „Analiza nieudanych płatności i poprawek” oraz „Czas rozwiązywania błędów”.

Skąd pobrać

Należy szukać jawnych wpisów w tabeli dziennika błędów lub zmiany statusu na „Błąd” albo „Wymaga korekty” w tabeli transakcji. Zdarzenia te należy powiązać z identyfikatorem transakcji płatniczej.

Rejestrowanie

Zdarzenie jest rejestrowane wprost, gdy mechanizm walidacji lub przetwarzania systemu wykryje błąd.

Typ zdarzenia explicit
Zatwierdzono płatność
To ważny etap, na którym upoważniony użytkownik zatwierdza płatność, umożliwiając jej realizację. Zwykle jest rejestrowany jako jawne zdarzenie, gdy osoba zatwierdzająca wykonuje odpowiednią czynność w interfejsie systemu.
Dlaczego to ważne

To ważny punkt kontrolny i często istotne wąskie gardło. Analiza czasu oczekiwania przed tym etapem oraz długości cyklu zatwierdzania pomaga wskazać możliwości przyspieszenia płatności.

Skąd pobrać

Należy znaleźć jawne zdarzenie w tabeli dziennika zatwierdzeń lub zmianę statusu na „Zatwierdzona” w głównej tabeli transakcji, powiązaną z działaniem konkretnego użytkownika i znacznikiem czasu.

Rejestrowanie

Zdarzenie jest rejestrowane, gdy upoważniony użytkownik zatwierdzi płatność w systemie.

Typ zdarzenia explicit
Odrzucono płatność
Zdarzenie występuje, gdy osoba zatwierdzająca odrzuca zlecenie płatnicze. Często wymaga to poprawienia i ponownego przesłania zlecenia. Jest to jawne zdarzenie, które zatrzymuje dalszy przebieg płatności i rozpoczyna pętlę poprawek.
Dlaczego to ważne

Pozwala wykryć poprawki i nieefektywność procesu. Śledzenie częstotliwości odrzuceń pomaga zdiagnozować problemy z jakością danych wejściowych lub zasadami składania zleceń oraz analizować poprawki.

Skąd pobrać

Zdarzenie jest rejestrowane w dzienniku zatwierdzeń lub jako zmiana statusu na „Odrzucona” w tabeli transakcji. Może zawierać kod przyczyny odrzucenia.

Rejestrowanie

Zdarzenie jest rejestrowane, gdy osoba zatwierdzająca odrzuci płatność w systemie.

Typ zdarzenia explicit
Płatność nie powiodła się
Końcowy status oznaczający, że płatności nie można zrealizować z powodu problemu, którego nie da się usunąć. Różni się od błędu, który można naprawić, i oznacza definitywne zakończenie procesu niepowodzeniem.
Dlaczego to ważne

Śledzenie tego zdarzenia końcowego pozwala obliczyć ogólny odsetek nieudanych płatności. Analiza przyczyn niepowodzeń może pomóc poprawić jakość danych i reguły procesu.

Skąd pobrać

Wnioskowane na podstawie końcowego statusu, takiego jak „Niepowodzenie”, „Anulowano” lub „Odrzucono przez bank”, który nie ulega później zmianie.

Rejestrowanie

Wnioskowane na podstawie końcowego statusu niepowodzenia w rekordzie płatności.

Typ zdarzenia inferred
Potwierdzono płatność
Oznacza wewnętrzne potwierdzenie, że płatność została pomyślnie przetworzona i otrzymano potwierdzenie jej realizacji. Często uruchamia powiadomienie odbiorcy płatności lub innych systemów wewnętrznych.
Dlaczego to ważne

Ten etap ma zasadnicze znaczenie przy ocenie dotrzymywania terminów płatności i wskaźnika płatności zrealizowanych w terminie. Zapewnia dokładny znacznik czasu, w którym organizacja uznaje płatność za zrealizowaną.

Skąd pobrać

Zwykle można go wywnioskować ze zmiany statusu transakcji płatniczej na „Potwierdzona” lub „Zakończona” po otrzymaniu potwierdzenia z sieci zewnętrznej.

Rejestrowanie

Można go wywnioskować ze zmiany statusu na „Potwierdzona” lub „Przetworzona”.

Typ zdarzenia inferred
Przekazano płatność do zatwierdzenia
Oznacza, że płatność przeszła wstępną walidację i została przekazana do wymaganej akceptacji kierowniczej lub finansowej. Zwykle jest to rejestrowane jako zmiana statusu w workflow płatności.
Dlaczego to ważne

To początek podprocesu zatwierdzania. Pomiar czasu od tego momentu do etapu „Płatność zatwierdzona” ma zasadnicze znaczenie dla dashboardu „Analiza czasu zatwierdzania płatności”.

Skąd pobrać

Można ją wywnioskować ze zmiany pola statusu płatności w danych transakcji, na przykład z przejścia do statusu „Oczekuje na zatwierdzenie”.

Rejestrowanie

Można ją wywnioskować ze zmiany statusu na „Oczekuje na zatwierdzenie” lub podobny oraz odpowiadającego jej znacznika czasu.

Typ zdarzenia inferred
Rozwiązano błąd płatności
Oznacza moment, w którym użytkownik poprawił wcześniej wykryty błąd, a płatność została ponownie przekazana do przetwarzania. Zdarzenie to często wnioskuje się ze zmiany statusu płatności ze stanu błędu na zwykły status przetwarzania.
Dlaczego to ważne

To działanie zamyka obsługę wyjątku. Czas od zdarzenia „Wykryto błąd płatności” do tego momentu to czas rozwiązania błędu, ważna miara sprawności operacyjnej.

Skąd pobrać

Wnioskowane na podstawie zmiany statusu ze stanu „Błąd” na status przetwarzania, taki jak „Oczekuje na zatwierdzenie” lub „Zatwierdzono”. Może to być również jawny wpis o działaniu użytkownika.

Rejestrowanie

Wnioskowane na podstawie zmiany statusu ze stanu błędu, która wskazuje, że wprowadzono korektę.

Typ zdarzenia inferred
Uzgodniono płatność
Oznacza końcowy etap księgowania, w którym transakcja płatnicza zarejestrowana w ACI jest dopasowywana do wyciągów bankowych lub zapisów księgowych. Może to być jawne zdarzenie z modułu uzgadniania albo zdarzenie wnioskowane na podstawie zmiany statusu.
Dlaczego to ważne

To działanie pozwala mierzyć sprawność uzgadniania w back office. Opóźnienia mogą obniżyć dokładność raportowania finansowego i utrudnić wykrycie nierozliczonych płatności.

Skąd pobrać

Informacje mogą pochodzić z dedykowanego modułu uzgadniania w ACI lub z zewnętrznego systemu ERP. Zdarzenie można zarejestrować na podstawie zmiany statusu rekordu płatności na „Uzgodniono”.

Rejestrowanie

Wnioskowane na podstawie końcowej zmiany statusu na „Uzgodniono” lub danych uzgodnieniowych połączonych za pomocą identyfikatora płatności.

Typ zdarzenia inferred
Wysłano instrukcję płatniczą
Oznacza moment, w którym instrukcja płatnicza zostaje przygotowana i wysłana do zewnętrznej sieci płatniczej, takiej jak SWIFT, ACH lub SEPA. Systemy ACI jawnie rejestrują to przekazanie na potrzeby audytu i śledzenia transakcji.
Dlaczego to ważne

W przypadku wielu rodzajów płatności jest to „punkt bez odwrotu”. Śledzenie tego etapu pozwala mierzyć czas przetwarzania wewnętrznego, zanim realizacja będzie zależeć od podmiotów zewnętrznych.

Skąd pobrać

Prawie zawsze jest to jawne zdarzenie zapisane w dzienniku transakcji lub komunikatów ACI, często wraz z numerem referencyjnym właściwym dla danej sieci.

Rejestrowanie

Jawny wpis w dzienniku jest tworzony w chwili wysłania komunikatu płatniczego do sieci zewnętrznej.

Typ zdarzenia explicit
Zweryfikowano dane płatności
Oznacza zakończenie automatycznych lub ręcznych kontroli poprawności danych płatności, takich jak dane odbiorcy i kody bankowe. Czynność tę często można wywnioskować ze zmiany statusu transakcji z „Nowa” na „Zweryfikowana” lub „Oczekuje na zatwierdzenie”.
Dlaczego to ważne

Pozwala ocenić efektywność wstępnej walidacji danych. Opóźnienia na tym etapie mogą tworzyć wąskie gardła na wcześniejszych etapach i zwiększać ryzyko błędów płatności w dalszej części procesu.

Skąd pobrać

Można ją wywnioskować ze zmian statusu w głównej tabeli transakcji płatniczych. Należy porównać znaczniki czasu statusu „Utworzona” z późniejszym statusem „Zweryfikowana” lub podobnym.

Rejestrowanie

Można ją wywnioskować ze zmiany pola statusu płatności, na przykład z „Wprowadzona” na „Zweryfikowana”.

Typ zdarzenia inferred
Zalecane Opcjonalne

Instrukcje pobierania danych

Jak pobrać dane z ACI Worldwide

Gotowi do rozpoczęcia?

Skorzystaj z tego szablonu, aby rozpocząć pobieranie danych dotyczących obsługi płatności. Już dziś odkryj przydatne informacje i usprawnij finansowe workflow.

Usprawnij obsługę płatności. Rozpocznij okres próbny

Ogranicz wyjątki w płatnościach i osiągnij 98% płatności przetwarzanych bez ręcznej obsługi.

Rozpocznij okres próbny

Karta kredytowa nie jest wymagana, konfiguracja zajmuje kilka minut