Datová šablona pro zpracování plateb
Datová šablona pro zpracování plateb
- Doporučené atributy ke shromáždění
- Aktivity, které je vhodné sledovat
- Pokyny k extrakci dat z ACI Worldwide
Atributy zpracování plateb
| Název | Popis | ||
|---|---|---|---|
| Časové razítko události EventTimestamp | Konkrétní datum a čas, kdy k aktivitě došlo. | ||
| Popis Tento atribut zaznamenává přesný okamžik, kdy v prostředí ACI došlo k události. Používá se k výpočtu všech časových ukazatelů, včetně doby průchodu procesem, délky schvalování a rychlosti zpracování. Pro přesné seřazení rychle po sobě následujících automatizovaných kroků se doporučuje přesnost na milisekundy. Proč je to důležité Je nezbytný pro řazení událostí a výpočet doby trvání. Kde data získat V historii transakcí nebo auditních tabulkách vyhledejte sloupce „Created Date“ nebo „Update Date“. Příklady 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| ID platební transakce PaymentTransactionId | Jedinečný identifikátor konkrétní platební instrukce v systému ACI. | ||
| Popis Tento atribut slouží jako hlavní identifikátor pro analýzu process mining a propojuje všechny události související s jedním požadavkem na platbu. V systémech ACI Worldwide, například MTS nebo UPP, jde o jedinečné referenční číslo přidělené transakci při zadání. Umožňuje rekonstruovat průběh platby od počátečního požadavku přes ověření a schválení až po konečné vypořádání. Proč je to důležité Jde o základní ID případu potřebné ke seskupení jednotlivých událostí do instancí procesu. Kde data získat V transakčních hlavičkových tabulkách hledejte pole označená například TRN_REF, REFERENCE_NUM nebo UUID v hlavním transakčním protokolu. Příklady TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| Název aktivity ActivityName | Konkrétní krok nebo změna stavu, ke které došlo během životního cyklu platby. | ||
| Popis Tento atribut určuje uzel události v mapě procesu, například „Vytvořen požadavek na platbu“ nebo „Převedeny prostředky“. V systémech ACI se obvykle odvozuje z kódů stavů, typů operací v auditním protokolu nebo změn stavu workflow. Pro smysluplné zobrazení je důležité převést tyto technické stavy na srozumitelné obchodní aktivity. Proč je to důležité Určuje tok procesu a je nezbytný pro zobrazení posloupnosti provozních kroků. Kde data získat Odvozuje se z kódů stavů, například 100=Vytvořeno, 200=Ověřeno, nebo ze sloupců akcí v auditním protokolu. Příklady Vytvoření požadavku na platbuAutorizace platbyVypořádání platbyPlatba selhala | |||
| Částka platby PaymentAmount | Peněžní hodnota platební transakce. | ||
| Popis Udává finanční hodnotu převáděných prostředků. Jde o důležitý kontextový údaj pro analýzu „Objemu zpracovaných plateb“ a stanovení priorit při řešení úzkých míst. U plateb vysoké hodnoty bývá schvalovací postup důkladnější než u automaticky zpracovávaných plateb nízké hodnoty, což lze sledovat analýzou variant. Proč je to důležité Umožňuje rozdělit platby podle hodnoty a vypočítat celkový zpracovaný objem. Kde data získat V podrobných transakčních tabulkách hledejte pole jako AMT, TRANS_AMOUNT nebo PRINCIPAL_AMOUNT. Příklady 1500.00250000.5050.001000000.00 | |||
| Datum splatnosti platby PaymentDueDate | Datum, do kterého musí být platba vypořádána, aby byla považována za včasnou. | ||
| Popis Uchovává smluvní nebo požadované datum provedení. Porovnáním tohoto data se skutečným datem vypořádání se vypočítá KPI „Míra včasných plateb“ a získají se podklady pro dashboard „Dodržení data splatnosti plateb“. Proč je to důležité Slouží jako základ pro měření dodržení SLA a včasnosti plateb. Kde data získat V platebních instrukcích hledejte pole VALUE_DATE, EXECUTION_DATE nebo DUE_DATE. Příklady 2023-11-012023-11-05 | |||
| Kanál zpracování ProcessingChannel | Kanál, kterým byla platba zadána. | ||
| Popis Označuje místo zadání platby, například mobilní aplikaci, webový portál, API nebo nahrání souboru. Analýza variant procesu plateb pomáhá zjistit, zda se u některých kanálů častěji objevují chyby nebo zpoždění. Proč je to důležité Umožňuje porovnat výkonnost podle způsobu zadání. Kde data získat V hlavičce transakce hledejte sloupce CHANNEL, SOURCE_TYPE nebo INPUT_METHOD. Příklady SWIFTInternetové bankovnictvíMobilní aplikaceNahrání souboru | |||
| Kód chyby ErrorCode | Kód vytvořený při selhání platby nebo při potřebě její opravy. | ||
| Popis Zaznamenává konkrétní příčinu události „Platba selhala“ nebo „Zjištěna chyba platby“. Seskupení podle tohoto atributu v dashboardu „Analýza neúspěšných plateb a oprav“ pomáhá určit nejčastější příčiny selhání, například „Nedostatek prostředků“ nebo „Neplatný účet“. Proč je to důležité Je nezbytný pro analýzu hlavních příčin selhání procesu. Kde data získat V protokolech chyb nebo sloupcích s důvodem stavu hledejte pole jako REASON_CODE nebo RETURN_CODE. Příklady R01AM04BE05TECH_ERR_001 | |||
| Měna platby PaymentCurrency | Kód měny podle ISO pro částku platby. | ||
| Popis Určuje měnu, ve které je uvedena hodnota Proč je to důležité Je nutná pro správnou interpretaci částky platby. Kde data získat V podrobných transakčních tabulkách hledejte pole jako CCY, CURRENCY_CODE nebo ISO_CODE. Příklady USDEURGBPJPY | |||
| Oddělení Department | Interní oddělení odpovědné za aktuální aktivitu. | ||
| Popis Přiřazuje Proč je to důležité Umožňuje souhrnně porovnat výkonnost podle obchodní funkce. Kde data získat Odvozuje se z uživatelských tabulek nebo mapování organizační struktury. Příklady ProvozComplianceTreasuryPodpora IT | |||
| Typ platby PaymentType | Klasifikace platebního nástroje. | ||
| Popis Určuje kategorii platby, například Wire, ACH, SEPA nebo RTGS. Jednotlivé typy plateb se často výrazně liší SLA i průběhem procesu. Tento atribut je jedním z hlavních filtrů v dashboardu „Doba průchodu platby od začátku do konce“. Proč je to důležité Je důležitý pro rozlišení rychlých a dávkově zpracovávaných plateb. Kde data získat V hlavičce transakce hledejte pole PMT_TYPE, INSTRUMENT_TYPE nebo SERVICE_ID. Příklady Tuzemský bankovní převodMezinárodní bankovní převodACH kreditní platbaOkamžitá platba | |||
| Uživatel události EventUser | ID uživatele nebo systémového agenta odpovědného za aktivitu. | ||
| Popis Zaznamenává, kdo akci provedl, ať už šlo o uživatele, například při schvalování, nebo o systémový účet, například při automatickém vypořádání. Tento atribut je důležitý pro analýzu úzkých míst, protože pomáhá zjistit, zda jsou konkrétní uživatelé nebo fronty přetížené. Proč je to důležité Umožňuje analyzovat zdroje a kontrolovat oddělení pravomocí. Kde data získat Auditní protokoly nebo sloupce „UpdatedBy“ v transakčních tabulkách. Příklady SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS | |||
| Vyžaduje opravu IsRework | Příznak označující, zda se u platby opakovaly některé aktivity. | ||
| Popis Logická hodnota vypočítaná při zpracování dat. Nastaví se na true, pokud se aktivita, například „Ověření údajů o platbě“, opakuje nebo pokud je zjištěn cyklus chyb. Tento příznak se používá pro KPI „Míra oprav plateb“. Proč je to důležité Rychle odhalí neefektivní případy bez složitých dotazů na proces. Kde data získat V datovém toku se vypočítá kontrolou duplicitních aktivit v jednotlivých případech. Příklady truefalse | |||
| Doba schvalování ApprovalCycleTime | Doba strávená ve fázi schvalování. | ||
| Popis Vypočítává dobu mezi událostmi „Platba odeslána ke schválení“ a „Platba schválena“ nebo „Platba zamítnuta“. Tento ukazatel se používá v dashboardu „Analýza doby schvalování plateb“ a upozorňuje na zpoždění při rozhodování uživatelů. Proč je to důležité Odděluje část procesu závislou na rozhodnutí uživatele. Kde data získat Výpočet: Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval). Příklady 4 hodiny15 minut | |||
| ID odsouhlasení ReconciliationId | Identifikátor propojující platbu s hlavní účetní knihou nebo záznamem o odsouhlasení. | ||
| Popis Toto ID se vyplní při aktivitě „Platba odsouhlasena“. Potvrzuje, že platba ve zpracovatelském systému odpovídá záznamu v účetním systému. Pokud u vypořádané platby chybí, může to znamenat, že odsouhlasení selhalo. Proč je to důležité Je důležité pro dashboard „Efektivita odsouhlasení plateb“. Kde data získat V tabulkách odsouhlasení hledejte pole jako RECON_REF nebo GL_REF. Příklady REC-9921GL-Entry-2023-11 | |||
| Jméno příjemce BeneficiaryName | Název subjektu, který platbu přijímá. | ||
| Popis Určuje protistranu transakce. Analýza tohoto pole může pomoci odhalit konkrétní dodavatele nebo zákazníky spojené s častými opravami či zpožděními a podpořit tak analýzu neúspěšných plateb a oprav. Proč je to důležité Určuje příjemce platby a umožňuje analýzu z pohledu zákazníka. Kde data získat V řádcích s podrobnostmi o platbě hledejte pole jako CREDITOR_NAME, BENE_NAME nebo PAYEE. Příklady Acme CorpGlobal Supplies LtdJohn Smith | |||
| Platba je opožděná IsPaymentLate | Příznak označující, zda byla platba vypořádána po datu splatnosti. | ||
| Popis Logická hodnota, která porovnává skutečné datum vypořádání s hodnotou Proč je to důležité Zjednodušuje vykazování shody. Kde data získat Výpočet: SettlementDate > PaymentDueDate. Příklady truefalse | |||
| Poslední aktualizace dat LastDataUpdate | Časové razítko poslední extrakce nebo aktualizace záznamu v datovém modelu. | ||
| Popis Sleduje aktuálnost dat použitých v analýze. Nejde o čas procesní události, ale o technický čas načtení dat. Analytici tak vědí, zda pracují s aktuálními, nebo historickými daty. Proč je to důležité Pomáhá ověřit aktuálnost dat a odhalit zastaralé údaje v dashboardech. Kde data získat Systémový čas při spuštění skriptu ETL. Příklady 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
| Region původu OriginatingRegion | Zeměpisný region, odkud požadavek na platbu pochází. | ||
| Popis Označuje fyzické nebo logické umístění žadatele. Analýza variant procesu plateb pomáhá zjistit, zda se v některých regionech používají nestandardní postupy nebo dochází k častějšímu zamítání plateb. Proč je to důležité Poskytuje zeměpisný kontext pro hodnocení výkonnosti procesu. Kde data získat V hlavičce transakce se obvykle odvozuje z kódu pobočky nebo země. Příklady Severní AmerikaEMEAAPAC | |||
| Zdrojový systém SourceSystem | Název systému, ze kterého pocházejí data o události. | ||
| Popis Určuje konkrétní aplikaci nebo modul v prostředí ACI Worldwide, například ACI MTS nebo ACI UPF, případně externí systémy zapojené do procesu. Je to důležité zejména při propojování dat z více účetních knih nebo pokud platba prochází externím clearingovým centrem. Proč je to důležité Udává, odkud byla data získána, což pomáhá při hledání problémů v původu dat. Kde data získat Při extrakci se zadá pevná hodnota nebo se odvodí ze sloupce SystemID, pokud existuje více instancí. Příklady ACI MTSACI UPPSAP GLSwift Gateway | |||
Aktivity při zpracování plateb
| Aktivita | Popis | ||
|---|---|---|---|
| Autorizace platby | Označuje systémovou autorizaci platby po schválení člověkem. Systém ověří dostupnost prostředků nebo zkontroluje pravidla proti podvodům. Událost může být zaznamenána přímo nebo odvozena ze změny stavu, která značí připravenost k provedení. | ||
| Proč je to důležité Jde o důležitý kontrolní bod před zadáním převodu prostředků. Prodlevy v této fázi mohou ukazovat na problémy s výkonem systému nebo s kontrolami dodržování pravidel a odhalováním podvodů. Kde data získat Hledejte výslovný záznam v protokolu zpracování systému nebo bezpečnostním protokolu. Událost lze také odvodit ze změny stavu z „Approved“ na „Authorized for Payment“. Zachycení Zaznamená ji platební modul systému po úspěšném dokončení závěrečných interních kontrol. Typ události explicit | |||
| Převod prostředků | Označuje přijetí potvrzení od platební sítě, že prostředky byly úspěšně odepsány z účtu plátce. Obvykle se zaznamená na základě příchozí stavové zprávy ze sítě. | ||
| Proč je to důležité Potvrzuje úspěšné provedení platby externí sítí. Označuje začátek období vypořádání a je důležitým vstupem pro KPI „Average Payment Settlement Time“. Kde data získat Jde o výslovnou událost vyvolanou příchozí zprávou o změně stavu, například MT103 ze SWIFT nebo potvrzením ACH, která aktualizuje záznam o platbě. Zachycení Zaznamená se při přijetí potvrzovací zprávy z externího clearingového systému. Typ události explicit | |||
| Schválení platby | Důležitý milník, při kterém oprávněný uživatel schválí platbu a umožní její provedení. Obvykle se zaznamená jako výslovná událost, když schvalovatel provede příslušný úkon v uživatelském rozhraní systému. | ||
| Proč je to důležité Jde o důležitý kontrolní bod, který často představuje výrazné úzké místo. Analýza čekání před tímto krokem a délky schvalovacího cyklu pomáhá najít možnosti, jak platby urychlit. Kde data získat Hledejte výslovnou událost v tabulce záznamů o schvalování nebo změnu stavu na „Approved“ v hlavní tabulce transakcí, která je spojena s konkrétní akcí uživatele a časovým razítkem. Zachycení Zaznamená se, když oprávněný uživatel dokončí schválení v systému. Typ události explicit | |||
| Vypořádání platby | Závěrečné potvrzení, že platební proces skončil a prostředky byly připsány příjemci. Tím se transakce uzavírá. Jde o důležitou událost, která označuje úspěšné dokončení životního cyklu platby. | ||
| Proč je to důležité Jde o hlavní koncovou událost úspěšného procesu. Používá se k výpočtu celkové doby průchodu procesem a propustnosti a je důležitá pro téměř všechny dashboardy sledující výkonnost procesu od začátku do konce. Kde data získat Obvykle jde o výslovnou událost zaznamenanou při přijetí závěrečného potvrzení o vypořádání ze sítě nebo při aktualizaci interní účetní knihy, která potvrzuje dokončení transakce. Zachycení Zaznamená se po přijetí souboru nebo zprávy o konečném vypořádání a změní stav na „Vypořádáno“. Typ události explicit | |||
| Vytvoření požadavku na platbu | Tato aktivita označuje zahájení nové platební transakce v systému ACI Worldwide. Obvykle jde o zaznamenanou událost, ke které dojde, když uživatel nebo navazující systém odešle požadavek na platbu. Vznikne tak nový záznam transakce s jedinečným ID. | ||
| Proč je to důležité Jde o hlavní počáteční událost platebního procesu. Doba od této aktivity do dokončení transakce představuje celkovou dobu průchodu procesem a je důležitým ukazatelem jeho efektivity. Kde data získat Pravděpodobně jde o výslovně zaznamenanou událost v hlavní tabulce transakcí nebo ve vyhrazeném záznamu událostí v ACI. Hledejte časové razítko vytvoření spojené s Payment Transaction ID. Zachycení Určuje se podle záznamu o vytvoření nebo výslovné události „Create“ v záznamu transakcí. Typ události explicit | |||
| Zjištěna chyba platby | Označuje, že systém v některé fázi zjistil problém s platbou, například neplatná data nebo upozornění týkající se shody. Tato událost se obvykle zaznamenává výslovně spolu s příslušným kódem chyby. | ||
| Proč je to důležité Tato aktivita je výchozím bodem pro analýzu oprav a zpracování výjimek. Je nezbytná pro dashboardy „Analýza neúspěšných plateb a oprav“ a „Doba řešení chyb“. Kde data získat Hledejte výslovné záznamy v tabulce protokolu chyb nebo změnu stavu na „Chyba“ či „Vyžaduje opravu“ v transakční tabulce. Tyto události propojte s ID platební transakce. Zachycení Výslovná událost se zaznamená, když validační nebo zpracovatelský modul systému označí chybu. Typ události explicit | |||
| Chyba platby vyřešena | Označuje okamžik, kdy uživatel opravil dříve zjištěnou chybu a platbu znovu odeslal ke zpracování. Často se odvozuje ze změny stavu platby z chybového na běžný stav zpracování. | ||
| Proč je to důležité Tato aktivita uzavírá cyklus řešení výjimky. Doba mezi událostí „Zjištěna chyba platby“ a touto událostí představuje dobu řešení chyby, která je důležitým ukazatelem efektivity provozu. Kde data získat Odvozuje se ze změny stavu z „Chyba“ na stav zpracování, například „Čeká na schválení“ nebo „Ověřeno“. Může jít také o výslovný záznam akce uživatele. Zachycení Odvozuje se ze změny stavu z chybového stavu, která značí provedení opravy. Typ události inferred | |||
| Odeslání platby ke schválení | Označuje, že platba prošla počáteční kontrolou a byla předána ke schválení příslušnému vedoucímu nebo finančnímu pracovníkovi. Tato událost se obvykle zaznamená změnou stavu ve workflow platby. | ||
| Proč je to důležité Tímto začíná dílčí proces schvalování. Doba od tohoto okamžiku do „Payment Approved“ je důležitá pro dashboard „Payment Approval Cycle Time Analysis“. Kde data získat Lze odvodit ze změny pole stavu platby v datech transakce, například při přechodu do stavu „Pending Approval“. Zachycení Lze odvodit ze změny stavu na „Pending Approval“ nebo podobný stav a odpovídajícího časového razítka. Typ události inferred | |||
| Odeslání platebního příkazu | Označuje okamžik, kdy je platební příkaz sestaven a odeslán do externí platební sítě, například SWIFT, ACH nebo SEPA. Systémy ACI toto předání výslovně zaznamenávají pro účely auditu a sledování. | ||
| Proč je to důležité U mnoha typů plateb jde o okamžik, po kterém už nelze proces vrátit zpět. Jeho sledování pomáhá měřit dobu interního zpracování před tím, než začnou rozhodovat externí systémy. Kde data získat Téměř vždy jde o výslovnou událost zaznamenanou v protokolu transakcí nebo zpráv ACI, často včetně referenčního čísla konkrétní sítě. Zachycení Při odeslání platební zprávy do externí sítě se vytvoří výslovný záznam. Typ události explicit | |||
| Ověření údajů o platbě | Označuje dokončení automatických nebo ručních kontrol správnosti údajů o platbě, například údajů o příjemci a bankovních kódů. Tuto aktivitu lze často odvodit ze změny stavu transakce z „New“ na „Validated“ nebo „Pending Approval“. | ||
| Proč je to důležité Sleduje efektivitu počátečních kontrol dat. Prodlevy v této fázi mohou vytvořit úzká místa v navazujících krocích a zvýšit pravděpodobnost pozdějších chyb v platbě. Kde data získat Lze odvodit ze změn stavových polí v hlavní tabulce platebních transakcí. Porovnejte časová razítka stavu „Created“ a následujícího stavu „Validated“ nebo podobného stavu. Zachycení Lze odvodit ze změny pole stavu platby, například z „Entered“ na „Validated“. Typ události inferred | |||
| Platba odsouhlasena | Představuje závěrečný účetní krok, při kterém se platební transakce zaznamenaná v ACI porovná s bankovním výpisem nebo účetními záznamy. Může jít o výslovnou událost z modulu odsouhlasení nebo o událost odvozenou ze změny stavu. | ||
| Proč je to důležité Tato aktivita měří efektivitu odsouhlasení v back office. Zpoždění mohou ovlivnit přesnost finančního výkaznictví a skrýt nevyřešené problémy s platbami. Kde data získat Tyto informace mohou pocházet z vyhrazeného modulu odsouhlasení v ACI nebo z externího systému ERP. Zaznamenají se při změně stavu platby na „Odsouhlaseno“. Zachycení Odvozuje se z konečné změny stavu na „Odsouhlaseno“ nebo z dat o odsouhlasení propojených podle ID platby. Typ události inferred | |||
| Platba selhala | Konečný stav označující, že platbu nebylo možné dokončit kvůli neřešitelnému problému. Liší se od chyby, kterou lze napravit, a znamená definitivní ukončení platby neúspěchem. | ||
| Proč je to důležité Sledování této koncové události je důležité pro výpočet celkové míry neúspěšných plateb. Analýza příčin může pomoci zlepšit kvalitu dat a pravidla procesu. Kde data získat Odvozuje se z konečného stavu, například „Selhalo“, „Zrušeno“ nebo „Zamítnuto bankou“, v transakčních datech, který se už následně nezmění. Zachycení Odvozuje se z konečného neúspěšného stavu v záznamu o platbě. Typ události inferred | |||
| Potvrzení platby | Označuje interní potvrzení, že platba byla úspěšně zpracována a že dorazilo potvrzení o jejím provedení. Často spouští informování příjemce nebo jiných interních systémů. | ||
| Proč je to důležité Tento milník je důležitý pro měření dodržení termínu splatnosti a podílu včasných plateb. Poskytuje přesný časový údaj o tom, kdy organizace považuje platbu za úspěšně provedenou. Kde data získat Obvykle se odvozuje ze změny stavu v tabulce platebních transakcí na „Confirmed“ nebo „Completed“ po přijetí potvrzení z externí sítě. Zachycení Lze odvodit ze změny stavu na „Confirmed“ nebo „Processed“. Typ události inferred | |||
| Zamítnutí platby | Nastane, když schvalovatel zamítne požadavek na platbu. Často je pak nutné údaje opravit a požadavek odeslat znovu. Jde o výslovnou událost, která zastaví další průběh platby a zahájí opakované zpracování. | ||
| Proč je to důležité Odhaluje opakované opravy a neefektivitu procesu. Sledování četnosti zamítnutí pomáhá odhalit problémy s kvalitou původních dat nebo pravidly pro podávání požadavků a podporuje analýzu opakovaných oprav. Kde data získat Zaznamená se jako výslovná událost v záznamu o schvalování nebo jako změna stavu na „Rejected“ v tabulce transakcí. Událost může obsahovat kód důvodu zamítnutí. Zachycení Zaznamená se, když schvalovatel v systému dokončí zamítnutí. Typ události explicit | |||
Návody k extrakci dat
Kroky
Přístup k databázovému prostředí: Přihlaste se k instanci SQL Serveru, na které běží databáze ACI Postilion Realtime. Použijte SQL Server Management Studio (SSMS) nebo kompatibilní klientskou aplikaci.
Vyhledání hlavních tabulek: Najděte tabulky
post_tran(záznam transakcí) apost_tran_cust(rozšíření o vlastní data). Ověřte, že máte k těmto objektům oprávněníSELECT.Určení identifikátoru případu: Tento export používá
retrieval_reference_nrjakoPaymentTransactionId. Pokud vaše implementace používá jiný jedinečný klíč, například kombinacisystem_trace_audit_nratransmission_date_time, upravte podle toho výběr v dotazu.Nastavení parametrů filtru: Otevřete níže uvedený dotaz. Na začátku skriptu najděte proměnné
@StartDatea@EndDate. Nastavte požadované období exportu, například posledních 30 až 90 dnů, aby dotaz běžel efektivně.Kontrola logiky aktivit: Dotaz mapuje typy zpráv ISO 8583, například 0200 a 0210, a kódy odpovědí na 14 požadovaných aktivit process mining. Zkontrolujte příkazy
CASEa ověřte, že odpovídají nastavení vašeho rozhraní ACI.Spuštění dotazu: Spusťte celý skript. Pomocí
UNION ALLsjednotí různé stavy transakcí do jednoho formátu záznamu událostí.Kontrola výstupních dat: Ověřte, že výsledek obsahuje požadované sloupce:
PaymentTransactionId,ActivityNameaEventTimestamp. Zkontrolujte, zda některá důležitá pole neobsahují neočekávaně hodnotuNULL.Export dat: V SSMS klikněte pravým tlačítkem na mřížku s výsledky a uložte data jako soubor CSV, například
ACI_Payments_EventLog.csv.Příprava dat pro ProcessMind: Otevřete soubor CSV a ověřte, že
EventTimestampmá standardní formát YYYY-MM-DD HH:MM:SS a žePaymentAmountobsahuje pouze číselné hodnoty.Nahrání: Importujte ověřený soubor CSV do ProcessMind a namapujte sloupce v tomto pořadí na ID případu, Aktivitu a Časové razítko.
Konfigurace
- Časové období: Tabulky ACI
post_tranrychle rostou. Doporučujeme omezit extrakci na průběžné tříměsíční období nebo použít přepínání oddílů, pokud je k dispozici. - Kódy odpovědí: Dotaz předpokládá, že
rsp_code = '00'znamená úspěch. Pokud vaše instituce používá jiné kódy schválení či úspěchu, například '08' nebo '10', upravte filtry. - Typy zpráv (ISO 8583): Skript používá standardní typy zpráv (0100/0200 pro požadavky, 0210 pro odpovědi). Vlastní typy zpráv definované v konfiguraci
source_node_namemohou vyžadovat úpravy. - Výkon systému: Dotaz používá nápovědy
NOLOCK, aby neblokoval živé zpracování transakcí. V produkčním prostředí je neodstraňujte. - Měny: Částky se extrahují jako nezpracované hodnoty. Pokud při analýze potřebujete sjednotit více měn, použijte
tran_currency_code.
Ukázkový dotaz 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; Chcete začít?
Při extrakci dat o zpracování plateb postupujte podle této šablony. Získejte užitečné poznatky a zefektivněte finanční workflow.
Zefektivněte zpracování plateb: začněte se zkušební verzí
Omezte výjimky při platbách a dosáhněte 98% podílu plně automatického zpracování.
Bez platební karty, nastavení během několika minut