Szablon danych dotyczących obsługi płatności
Szablon danych dotyczących obsługi płatności
- Zalecane atrybuty do zebrania
- Najważniejsze aktywności do śledzenia
- Wskazówki dotyczące pobierania danych z ACI Worldwide
Atrybuty obsługi płatności
| 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 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ść 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 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 | |||
Aktywności w procesie obsługi płatności
| 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 | |||
Instrukcje pobierania danych
Kroki
Dostęp do środowiska bazy danych: Zaloguj się do instancji SQL Server z bazą ACI Postilion Realtime za pomocą SQL Server Management Studio (SSMS) lub zgodnego klienta.
Wskazanie głównych tabel: Znajdź tabele
post_tran(dziennik transakcji) ipost_tran_cust(rozszerzenie danych niestandardowych). Upewnij się, że masz uprawnieniaSELECTdo tych obiektów.Określenie identyfikatora sprawy: W tym eksporcie jako
PaymentTransactionIdużywany jestretrieval_reference_nr. Jeśli wdrożenie korzysta z innego unikatowego klucza, na przykładsystem_trace_audit_nrpołączonego ztransmission_date_time, odpowiednio zmień wybór pól w zapytaniu.Ustawienie parametrów filtrowania: Otwórz zapytanie poniżej. Na początku skryptu znajdź zmienne
@StartDatei@EndDate. Ustaw żądany zakres pobierania, na przykład ostatnie 30–90 dni, aby zoptymalizować wydajność.Sprawdzenie logiki aktywności: Zapytanie mapuje typy komunikatów ISO 8583 (np. 0200, 0210) i kody odpowiedzi na 14 wymaganych aktywności process mining. Sprawdź instrukcje
CASE, aby upewnić się, że odpowiadają konfiguracji interfejsu ACI.Uruchomienie zapytania: Wykonaj cały skrypt. Zapytanie używa
UNION ALL, aby ujednolicić różne stany transakcji w jednym formacie dziennika zdarzeń.Weryfikacja danych wyjściowych: Sprawdź, czy wyniki zawierają wymagane kolumny:
PaymentTransactionId,ActivityNameiEventTimestamp. Upewnij się, że żadne istotne pola nie zawierają nieoczekiwanych wartościNULL.Eksport danych: Kliknij prawym przyciskiem myszy siatkę wyników w SSMS i zapisz dane jako plik CSV, na przykład
ACI_Payments_EventLog.csv.Przygotowanie danych dla ProcessMind: Otwórz plik CSV i sprawdź, czy
EventTimestampma standardowy format (YYYY-MM-DD HH:MM:SS), aPaymentAmountzawiera wyłącznie wartości liczbowe.Przesłanie danych: Zaimportuj zweryfikowany plik CSV do ProcessMind i przypisz kolumny odpowiednio do Case ID, Activity i Timestamp.
Konfiguracja
- Zakres dat: Tabele ACI
post_transzybko przyrastają. Zdecydowanie zaleca się ograniczenie pobierania do kroczącego okresu 3 miesięcy lub użycie przełączania partycji, jeśli jest dostępne. - Kody odpowiedzi: Zapytanie zakłada, że
rsp_code = '00'oznacza powodzenie. Jeśli w Państwa instytucji używane są inne kody zatwierdzenia lub powodzenia (np. '08' albo '10'), należy zmienić filtry. - Typy komunikatów (ISO 8583): Skrypt korzysta ze standardowych typów komunikatów (0100/0200 dla żądań, 0210 dla odpowiedzi). Własne typy komunikatów zdefiniowane w konfiguracji
source_node_namemogą wymagać zmian. - Wydajność systemu: Zapytanie używa wskazówek
NOLOCK, aby nie blokować bieżącej obsługi transakcji. Nie należy ich usuwać w środowisku produkcyjnym. - Waluty: Kwoty są pobierane jako wartości surowe. Jeśli analiza wymaga ujednolicenia wielu walut, należy użyć
tran_currency_code.
Przykładowe zapytanie sql
DECLARE @StartDate DATETIME = '2023-01-01 00:00:00';
DECLARE @EndDate DATETIME = '2023-01-31 23:59:59';
/* 1. Payment Request Created: Initial transaction request received */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Request Created' AS ActivityName,
t.datetime_req AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Origination' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200') -- Authorization/Financial Request
UNION ALL
/* 2. Payment Details Validated: Inferred after request but before routing */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Details Validated' AS ActivityName,
DATEADD(second, 1, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Compliance' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200')
AND t.rsp_code = '00' -- Implies validation passed
UNION ALL
/* 3. Payment Sent For Approval: Routing to internal authorization */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Sent For Approval' AS ActivityName,
DATEADD(second, 2, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0100', '0200')
AND t.tran_amount_req > 1000 -- Example threshold for approval logic
UNION ALL
/* 4. Payment Approved: Successful response code logic */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Approved' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Approver' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type IN ('0110', '0210')
UNION ALL
/* 5. Payment Rejected: Specific rejection codes */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Rejected' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Risk Management' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code IN ('51', '05', '61') -- Insufficient funds, Do not honor, etc.
UNION ALL
/* 6. Payment Authorized: Successful authorization completion */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Authorized' AS ActivityName,
DATEADD(millisecond, 500, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0110' -- Authorization Response
UNION ALL
/* 7. Payment Instruction Sent: Handoff to Sink Node */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Instruction Sent' AS ActivityName,
DATEADD(second, 1, t.datetime_req) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
t.sink_node_name AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Network Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.sink_node_name IS NOT NULL
AND t.message_type IN ('0200', '0100')
UNION ALL
/* 8. Funds Transferred: External network confirmation */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Funds Transferred' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
t.sink_node_name AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Treasury' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210' -- Financial Response
UNION ALL
/* 9. Payment Confirmed: Final acknowledgment */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Confirmed' AS ActivityName,
DATEADD(second, 5, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Customer Service' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210'
UNION ALL
/* 10. Payment Settled: Settlement/Reconciliation message */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Settled' AS ActivityName,
ISNULL(t.settle_date, t.datetime_rsp) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Settlement Engine' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Accounting' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type = '0500' -- Reconciliation
AND t.rsp_code = '00'
UNION ALL
/* 11. Payment Failed: System Errors */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Failed' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'IT Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code IN ('91', '96', '06') -- Issuer down, System malfunction
UNION ALL
/* 12. Payment Error Identified: General Error */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Error Identified' AS ActivityName,
t.datetime_rsp AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
t.rsp_code AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Compliance' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code NOT IN ('00')
AND t.message_type IN ('0210', '0110')
UNION ALL
/* 13. Payment Error Resolved: Reversal or Correction followed by Success */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Error Resolved' AS ActivityName,
t.datetime_req AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'System' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
1 AS IsRework,
NULL AS EndToEndCycleTime,
'Operations' AS Department
FROM post_tran t WITH (NOLOCK)
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.message_type IN ('0400', '0420') -- Reversal/Advice
UNION ALL
/* 14. Payment Reconciled: Batch processing flag from Custom Table */
SELECT
t.retrieval_reference_nr AS PaymentTransactionId,
'Payment Reconciled' AS ActivityName,
ISNULL(c.recon_date, DATEADD(hour, 24, t.datetime_req)) AS EventTimestamp,
CAST(t.tran_amount_req AS DECIMAL(18,2)) AS PaymentAmount,
t.tran_currency_code AS PaymentCurrency,
'Recon Module' AS EventUser,
t.source_node_name AS ProcessingChannel,
t.tran_type AS PaymentType,
NULL AS PaymentDueDate,
NULL AS ErrorCode,
0 AS IsRework,
NULL AS EndToEndCycleTime,
'Finance' AS Department
FROM post_tran t WITH (NOLOCK)
JOIN post_tran_cust c WITH (NOLOCK) ON t.post_tran_cust_id = c.post_tran_cust_id
WHERE t.datetime_req BETWEEN @StartDate AND @EndDate
AND t.rsp_code = '00'
AND t.message_type = '0210'
AND c.recon_date IS NOT NULL; 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.
Karta kredytowa nie jest wymagana, konfiguracja zajmuje kilka minut