Fizetési folyamat adatsablonja
Fizetési folyamat adatsablonja
- Javasolt attribútumok
- Nyomon követendő fő tevékenységek
- Adatkinyerési útmutató az ACI Worldwide rendszeréhez
A fizetési folyamat attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Esemény időbélyege EventTimestamp | Az esemény bekövetkezésének pontos dátuma és időpontja. | ||
| Leírás Ez az attribútum rögzíti, hogy az ACI-környezetben pontosan mikor történt egy esemény. Az időalapú mutatók, köztük a ciklusidők, a jóváhagyás időtartama és az átbocsátási arány kiszámítására szolgál. A gyors, automatizált lépések pontos sorrendjének meghatározásához lehetőleg ezredmásodperces pontosságot használjon. Miért fontos? Az események sorrendbe állításához és a teljesítési idők kiszámításához szükséges. Hol szerezhető be? Keresse a „Created Date” vagy „Update Date” oszlopot a tranzakciós előzményekben vagy a naplótáblákban. Példák 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| Payment Transaction ID PaymentTransactionId | Az ACI-rendszerben az adott fizetési megbízást egyedileg azonosító érték. | ||
| Leírás Ez az attribútum a process mining elemzés központi azonosítója, amely összekapcsolja az egyetlen fizetési kérelemhez tartozó összes eseményt. Az ACI Worldwide rendszereiben, például az MTS-ben vagy az UPP-ben ez a tranzakció rögzítésekor hozzárendelt egyedi hivatkozási szám. Segítségével rekonstruálható a fizetés teljes útja a kezdeti kérelemtől az ellenőrzésen és jóváhagyáson át a végső elszámolásig. Miért fontos? Ez az alapvető Case ID, amely az egyes események folyamatpéldányokba rendezéséhez szükséges. Hol szerezhető be? Keresse a tranzakciófejléc-táblákban, gyakran TRN_REF, REFERENCE_NUM vagy UUID néven a fő tranzakciós naplóban. Példák TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| Tevékenység neve ActivityName | A fizetési folyamat adott lépése vagy bekövetkezett állapotváltozása. | ||
| Leírás Ez az attribútum határozza meg a folyamattérkép eseménycsomópontját, például „Fizetési kérelem létrehozva” vagy „Összeg átutalva”. Az ACI-rendszerekben ez gyakran állapotkódokból, naplózott művelettípusokból vagy munkafolyamat-állapotváltozásokból származik. A technikai állapotok pontos megfeleltetése az érthető üzleti tevékenységeknek szükséges ahhoz, hogy a megjelenítés hasznos legyen. Miért fontos? Meghatározza a folyamat menetét, és szükséges a műveletek sorrendjének megjelenítéséhez. Hol szerezhető be? Állapotkódokból (például 100=Létrehozva, 200=Ellenőrizve) vagy a napló Action oszlopaiból származik. Példák Fizetési kérelem létrehozvaFizetés engedélyezveFizetés elszámolvaSikertelen fizetés | |||
| Eseményt végrehajtó felhasználó EventUser | A tevékenységért felelős felhasználó vagy rendszerügynök azonosítója. | ||
| Leírás Rögzíti, hogy ki hajtotta végre a műveletet: egy felhasználó, például a jóváhagyás során, vagy egy rendszerfiók, például az automatikus elszámoláskor. Ez az attribútum szükséges a „Szűk keresztmetszetek elemzése” során annak megállapításához, hogy egyes felhasználók vagy sorok túlterheltek-e. Miért fontos? Lehetővé teszi az erőforrások elemzését és a feladatkörök szétválasztásának ellenőrzését. Hol szerezhető be? Naplók vagy a tranzakciós táblák „UpdatedBy” oszlopa. Példák SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS | |||
| Feldolgozási csatorna ProcessingChannel | Az a csatorna, amelyen keresztül a fizetést elindították. | ||
| Leírás Megadja a fizetés indításának módját, például mobilalkalmazás, webes portál, API vagy fájlfeltöltés. A „Fizetési folyamatváltozatok elemzése” során összehasonlítható, hogy egyes csatornákon gyakoribbak-e a hibák vagy a késések. Miért fontos? A teljesítmény összehasonlítása a beviteli mód szerint. Hol szerezhető be? A tranzakció fejlécében, gyakran a CHANNEL, SOURCE_TYPE vagy INPUT_METHOD nevű oszlopban. Példák SWIFTInternetbankMobilalkalmazásFájlfeltöltés | |||
| Fizetés összege PaymentAmount | A fizetési tranzakció pénzben kifejezett értéke. | ||
| Leírás Megadja az átutalt összeget. Fontos háttéradat a „Fizetési átbocsátás” elemzéséhez és a szűk keresztmetszetek rangsorolásához. A nagy összegű fizetések gyakran szigorúbb jóváhagyási folyamaton mennek át, mint a kis összegű, automatizált tranzakciók. Miért fontos? Lehetővé teszi az adatok összeg szerinti csoportosítását és a feldolgozott teljes volumen kiszámítását. Hol szerezhető be? A tranzakció részleteit tartalmazó táblákban, jellemzően az AMT, TRANS_AMOUNT vagy PRINCIPAL_AMOUNT mezőben. Példák 1500.00250000.5050.001000000.00 | |||
| Fizetés pénzneme PaymentCurrency | A fizetés összegének ISO szerinti pénznemkódja. | ||
| Leírás Megadja, milyen pénznemben szerepel a Miért fontos? A fizetés összegének helyes értelmezéséhez szükséges. Hol szerezhető be? A tranzakció részleteit tartalmazó táblákban, jellemzően a CCY, CURRENCY_CODE vagy ISO_CODE mezőben. Példák USDEURGBPJPY | |||
| Fizetés típusa PaymentType | A fizetési eszköz besorolása. | ||
| Leírás A fizetés típusát jelöli, például Wire, ACH, SEPA vagy RTGS. Az egyes fizetéstípusokhoz gyakran eltérő SLA-k és folyamatok tartoznak. Ez az attribútum a „Fizetés teljes átfutási ideje” dashboard egyik fő szűrési szempontja. Miért fontos? A gyors és a kötegelt fizetési folyamatok megkülönböztetéséhez szükséges. Hol szerezhető be? A tranzakció fejlécében, például a PMT_TYPE, INSTRUMENT_TYPE vagy SERVICE_ID mezőben. Példák Belföldi átutalásNemzetközi átutalásACH-jóváírásAzonnali fizetés | |||
| Fizetési határidő PaymentDueDate | Az a dátum, ameddig a fizetést el kell számolni ahhoz, hogy határidőben teljesüljön. | ||
| Leírás A szerződésben rögzített vagy kért végrehajtási dátumot tárolja. Ezt a tényleges elszámolási dátummal összevetve kiszámítható a „Határidőben teljesített fizetések aránya” KPI, és támogatható a „Fizetési határidők betartása” dashboard. Miért fontos? Az SLA-k betartásának és a határidős teljesítésnek az alapja. Hol szerezhető be? A tranzakciós megbízásokban, általában a VALUE_DATE, EXECUTION_DATE vagy DUE_DATE mezőben. Példák 2023-11-012023-11-05 | |||
| Hibakód ErrorCode | A fizetés sikertelenségekor vagy javítás szükségessége esetén létrehozott kód. | ||
| Leírás Megadja a „Sikertelen fizetés” vagy a „Fizetési hiba észlelve” esemény konkrét okát. Ha ezt az attribútumot használja csoportosításra a „Fizetési hibák és javítások elemzése” dashboardon, azonosíthatók a leggyakoribb kiváltó okok, például „Nincs elegendő fedezet” vagy „Hibás számlaszám”. Miért fontos? A folyamat hibáinak kiváltó okait feltáró elemzéshez szükséges. Hol szerezhető be? Hibanaplókban vagy az állapot okát tartalmazó oszlopokban, gyakran a REASON_CODE vagy RETURN_CODE mezőben. Példák R01AM04BE05TECH_ERR_001 | |||
| Részleg Department | Az aktuális tevékenységért felelős belső részleg. | ||
| Leírás Az Miért fontos? Az üzleti területek teljesítményét összesíti. Hol szerezhető be? Felhasználói táblákból vagy a szervezeti hierarchia megfeleltetéséből származik. Példák MűködésComplianceTreasuryIT-támogatás | |||
| Történt javítás IsRework | Jelző, amely megmutatja, hogy a fizetés során ismétlődtek-e tevékenységek. | ||
| Leírás Az adatfeldolgozás során kiszámított logikai jelző. Értéke igaz, ha például a „Fizetési adatok ellenőrizve” tevékenység többször fordul elő, vagy a rendszer hibajavítási ciklust észlel. Ez alapján számítható ki a „Fizetési javítási arány” KPI. Miért fontos? Bonyolult folyamatlekérdezések nélkül is gyorsan azonosítja a nem hatékony eseteket. Hol szerezhető be? Az adatfeldolgozási folyamat számítja ki az esetenként ismétlődő tevékenységek ellenőrzésével. Példák truefalse | |||
| Egyeztetési azonosító ReconciliationId | A fizetést a főkönyvi vagy egyeztetési rekordhoz kapcsoló azonosító. | ||
| Leírás Ez az azonosító a „Fizetés egyeztetve” tevékenységkor kap értéket. Biztosítja, hogy a feldolgozó rendszerben szereplő fizetés megfeleljen a könyvelési rendszer tételének. Ha az elszámolt fizetésekhez nem tartozik ilyen azonosító, az egyeztetési hibára utal. Miért fontos? A „Fizetésegyeztetés hatékonysága” dashboardhoz szükséges. Hol szerezhető be? Egyeztetési táblákban vagy olyan mezőkben, mint a RECON_REF vagy GL_REF. Példák REC-9921GL-Entry-2023-11 | |||
| Forrásrendszer SourceSystem | Annak a rendszernek a neve, ahonnan az eseményadatok származnak. | ||
| Leírás Azonosítja az ACI Worldwide rendszerkörnyezetében használt alkalmazást vagy modult, például az ACI MTS-t vagy az ACI UPF-et, illetve a folyamatban részt vevő külső rendszereket. Ez különösen akkor fontos, ha több főkönyvből kell összekapcsolni az adatokat, vagy ha a fizetés külső elszámolóházon is áthalad. Miért fontos? Megmutatja, honnan származik a kinyert adat, ami hasznos az adatútvonal hibakeresésekor. Hol szerezhető be? Az adatkinyerés során rögzített érték, vagy több példány esetén a SystemID oszlopból származik. Példák ACI MTSACI UPPSAP GLSwift Gateway | |||
| Jóváhagyási ciklusidő ApprovalCycleTime | A jóváhagyási szakaszban eltelt idő. | ||
| Leírás A „Fizetés jóváhagyásra küldve” és a „Fizetés jóváhagyva” vagy „Elutasítva” esemény közötti időt számítja ki. Ez a mutató a „Fizetési jóváhagyás ciklusidejének elemzése” dashboardot táplálja, és megmutatja, hol késnek az emberi döntést igénylő lépések. Miért fontos? Elkülöníti a folyamat emberi közreműködést igénylő részét. Hol szerezhető be? Számítása: Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval). Példák 4 óra15 perc | |||
| Kedvezményezett neve BeneficiaryName | A fizetés címzettjének neve. | ||
| Leírás Azonosítja a tranzakció másik résztvevőjét. Az adat elemzésével felismerhetők azok a beszállítók vagy ügyfelek, akikhez sok javítás vagy késés kapcsolódik. Ez támogatja a „Fizetési hibák és javítások elemzését”. Miért fontos? Megadja, ki kapja a fizetést, ami hasznos az ügyfélközpontú elemzéshez. Hol szerezhető be? A fizetési tételekben, például a CREDITOR_NAME, BENE_NAME vagy PAYEE mezőben. Példák Acme CorpGlobal Supplies LtdJohn Smith | |||
| Késedelmes fizetés IsPaymentLate | Jelző, amely megmutatja, hogy a fizetést a határidő után számolták-e el. | ||
| Leírás Logikai jelző, amely a tényleges elszámolási dátumot a Miért fontos? Egyszerűbbé teszi a megfelelésről szóló jelentések készítését. Hol szerezhető be? Számítása: SettlementDate > PaymentDueDate. Példák truefalse | |||
| Kiindulási régió OriginatingRegion | Az a földrajzi régió, ahonnan a fizetési kérelmet elindították. | ||
| Leírás Megadja a kérelmező fizikai vagy logikai helyét. A „Fizetési folyamatváltozatok elemzése” során kideríthető, hogy egyes régiókban eltérő folyamatokat követnek-e, vagy gyakoribbak-e az elutasítások. Miért fontos? Földrajzi kontextust ad a folyamat teljesítményének értékeléséhez. Hol szerezhető be? A tranzakció fejlécéből származik, gyakran a Branch Code vagy Country Code mezőből. Példák Észak-AmerikaEMEAAPAC | |||
| Utolsó adatfrissítés LastDataUpdate | Annak időbélyege, hogy a rekordot mikor nyerték ki utoljára, vagy mikor frissítették az adatmodellben. | ||
| Leírás Az elemzésben használt adatok frissességét követi. Nem a folyamat eseményének időpontját jelöli, hanem az adatok betöltésének technikai időpontját. Segít az elemzőknek megállapítani, hogy valós idejű vagy korábbi adatokat látnak-e. Miért fontos? Segít naprakészen tartani az adatokat, és felismerni az elavult adatokat a dashboardokon. Hol szerezhető be? A rendszeridő az ETL-szkript futtatásakor. Példák 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
A fizetési folyamat tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Fizetés elszámolva | A fizetési folyamat befejezésének végső visszaigazolása. A pénz megérkezett a kedvezményezett számlájára, és a tranzakció lezárult. Ez a fizetési folyamat sikeres befejezését jelző fontos esemény. | ||
| Miért fontos? Ez a folyamat elsődleges sikeres záróeseménye. Az általános átfutási idő és az áteresztőképesség kiszámításához használják, és szinte minden, a teljes folyamatot mérő teljesítmény-dashboardhoz szükséges. Hol szerezhető be? Általában kifejezett eseményként rögzül, amikor megérkezik a hálózat végső elszámolási visszaigazolása, vagy amikor a belső főkönyvet frissítik a tranzakció lezárásának jelzésére. Rögzítés A végleges elszámolási fájl vagy üzenet beérkezésekor rögzítik, és az állapotot „Elszámolva” értékre állítják. Eseménytípus explicit | |||
| Fizetés engedélyezve | A fizetés rendszer általi engedélyezését jelzi az emberi jóváhagyás után. A rendszer ellenőrzi a fedezetet, vagy összeveti a tranzakciót a csalásmegelőzési szabályokkal. Ez kifejezett naplóbejegyzésként rögzülhet, vagy az engedélyezett, végrehajtásra kész állapotváltozásból következtethető ki. | ||
| Miért fontos? Ez kritikus ellenőrzési pont, mielőtt a pénzmozgásra vonatkozó utasításokat elküldik. Az itt jelentkező késések rendszerproblémára vagy a megfelelési, illetve csalásellenőrzési alrendszerek hibájára utalhatnak. Hol szerezhető be? Keressen kifejezett bejegyzést a rendszer feldolgozási vagy biztonsági naplójában. A tevékenység az „Approved” állapotról az „Authorized for Payment” állapotra váltásból is kikövetkeztethető. Rögzítés A rendszer fizetési motorja rögzíti a végső belső ellenőrzések sikeres lezárása után. Eseménytípus explicit | |||
| Fizetés jóváhagyva | Fontos mérföldkő: egy jogosult felhasználó jóváhagyja a fizetést, amely ezután továbbléphet a végrehajtásra. Ezt általában kifejezett eseményként rögzíti a rendszer, amikor a jóváhagyó a felhasználói felületen végrehajtja a műveletet. | ||
| Miért fontos? Ez a tevékenység fontos ellenőrzési pont, és gyakran jelentős szűk keresztmetszet. Az előtte eltelt várakozási idő és a jóváhagyási ciklus hosszának elemzése segít megtalálni a fizetések gyorsításának lehetőségeit. Hol szerezhető be? Keressen kifejezett eseményt a jóváhagyási naplótáblában, vagy a fő tranzakciós táblában az „Approved” állapotra váltást, amelyhez konkrét felhasználói művelet és időbélyeg tartozik. Rögzítés A rendszer akkor rögzíti, amikor egy jogosult felhasználó végrehajtja a jóváhagyást. Eseménytípus explicit | |||
| Fizetési hiba észlelve | Azt jelzi, hogy a rendszer a fizetési folyamat valamely pontján problémát észlelt, például hibás adatot vagy megfelelési riasztást. Az eseményt általában külön rögzítik a hozzá tartozó hibakóddal együtt. | ||
| Miért fontos? Ez a tevékenység a javítási és kivételkezelési elemzések kiindulópontja. Szükség van rá a „Fizetési hibák és javítások elemzése”, valamint a „Hibajavítási ciklusidő” dashboardhoz. Hol szerezhető be? Keressen külön bejegyzéseket a hibanapló táblájában, vagy „Hiba” vagy „Javítás szükséges” állapotváltozást a tranzakciós táblában. Ezeket az eseményeket a Payment Transaction ID-hoz kell kapcsolni. Rögzítés A rendszer ellenőrző vagy feldolgozó motorja hiba észlelésekor külön eseményt rögzít. Eseménytípus explicit | |||
| Fizetési kérelem létrehozva | Ez a tevékenység jelzi egy új fizetési tranzakció indítását az ACI Worldwide rendszerében. Általában akkor rögzül eseményként, amikor egy felhasználó vagy egy kapcsolódó rendszer fizetési kérelmet küld be, és létrejön egy egyedi azonosítójú tranzakciós rekord. | ||
| Miért fontos? Ez a fizetési folyamat elsődleges kezdő eseménye. A tevékenység és a folyamat befejezése közötti idő megmutatja a teljes átfutási időt, amely a folyamat általános hatékonyságának méréséhez szükséges. Hol szerezhető be? Ez valószínűleg egy kifejezetten rögzített esemény az ACI tranzakciós táblájában vagy egy külön eseménynaplóban. Keresse a Payment Transaction ID-hoz tartozó létrehozási időbélyeget. Rögzítés A létrehozási rekord vagy a tranzakciós naplóban szereplő kifejezett „Create” esemény alapján azonosítható. Eseménytípus explicit | |||
| Pénz átutalva | Azt jelzi, hogy a fizetési hálózat visszaigazolta a pénz sikeres levonását a fizető fél számlájáról. Ezt általában a hálózattól érkező állapotüzenet rögzíti. | ||
| Miért fontos? Megerősíti, hogy a külső hálózat sikeresen végrehajtotta a fizetést. Ezzel kezdetét veszi az elszámolási időszak, és ez az „Average Payment Settlement Time” KPI egyik fontos bemeneti adata. Hol szerezhető be? Ez kifejezett esemény, amelyet egy beérkező állapotfrissítő üzenet vált ki, például egy SWIFT MT103 üzenet vagy ACH-visszaigazolás. Az üzenet frissíti a fizetési rekordot. Rögzítés A rendszer akkor rögzíti, amikor megérkezik az elszámolóhálózat külső visszaigazolása. Eseménytípus explicit | |||
| Fizetés egyeztetve | Az utolsó könyvelési lépés, amikor az ACI-ban rögzített fizetési tranzakciót összevetik a bankszámlakivonattal vagy a főkönyvi tételekkel. Az egyeztető modul külön eseményként is rögzítheti, de állapotváltozásból is következtetni lehet rá. | ||
| Miért fontos? Ez a tevékenység a háttérirodai egyeztetési folyamat hatékonyságát méri. Az itt jelentkező késések ronthatják a pénzügyi jelentések pontosságát, és elfedhetik a még el nem számolt fizetésekkel kapcsolatos problémákat. Hol szerezhető be? Az adat származhat az ACI dedikált egyeztető moduljából vagy egy külső ERP-rendszerből. A fizetési rekord „Egyeztetve” állapotúra frissítése rögzítheti. Rögzítés A végleges „Egyeztetve” állapotfrissítésből vagy a Payment ID alapján összekapcsolt egyeztetési adatokból következtethető ki. Eseménytípus inferred | |||
| Fizetés elutasítva | Akkor történik, amikor a jóváhagyó elutasítja a fizetési kérelmet. Ilyenkor gyakran javításra és újbóli benyújtásra van szükség. Ez a kifejezett esemény megállítja a fizetés előrehaladását, és utómunkafolyamatot indít. | ||
| Miért fontos? Feltárja az utómunkát és a folyamat hatékonysági problémáit. Az elutasítások gyakoriságának nyomon követése segít felismerni a kezdeti adatminőséggel vagy a benyújtási szabályokkal kapcsolatos gondokat, és támogatja az utómunka elemzését. Hol szerezhető be? A jóváhagyási naplóban kifejezett eseményként vagy a tranzakciós táblában „Rejected” állapotváltozásként rögzül. Az esemény az elutasítás okát jelző kódot is tartalmazhat. Rögzítés A rendszer akkor rögzíti, amikor a jóváhagyó végrehajtja az elutasítást. Eseménytípus explicit | |||
| Fizetés jóváhagyásra elküldve | Azt jelzi, hogy a fizetés sikeresen átesett az első ellenőrzésen, és továbbították a szükséges vezetői vagy pénzügyi jóváhagyásra. Ezt általában a fizetési munkafolyamat állapotváltozása rögzíti. | ||
| Miért fontos? Ez jelöli a jóváhagyási alfolyamat kezdetét. A „Payment Approved” állapotig eltelt idő mérése elengedhetetlen a „Payment Approval Cycle Time Analysis” dashboardhoz. Hol szerezhető be? A tranzakciós adatok fizetési állapotmezőjének változásából állapítható meg, például amikor az állapot „Pending Approval” értékre vált. Rögzítés A „Pending Approval” vagy hasonló állapotra váltásból, valamint a hozzá tartozó időbélyegből következtethető ki. Eseménytípus inferred | |||
| Fizetés visszaigazolva | Azt jelzi, hogy a rendszer belsőleg visszaigazolta a fizetés sikeres feldolgozását és a külső visszaigazolás beérkezését. Ez gyakran elindítja a kedvezményezett vagy más belső rendszerek értesítését. | ||
| Miért fontos? Ez a mérföldkő elengedhetetlen a határidők betartásának és a határidőre teljesített fizetések arányának méréséhez. Egyértelmű időbélyeget ad arról, hogy a szervezet mikor tekinti sikeresen végrehajtottnak a fizetést. Hol szerezhető be? Ez általában a fizetési tranzakciós tábla állapotváltozásából következtethető ki. A külső hálózati visszaigazolás után az állapot „Confirmed” vagy „Completed” értékre vált. Rögzítés A „Confirmed” vagy „Processed” állapotra váltásból következtethető ki. Eseménytípus inferred | |||
| Fizetési adatok ellenőrizve | Azt jelzi, hogy befejeződtek a fizetési adatok, például a kedvezményezett adatainak és a bankkódoknak az ellenőrzései. Ezek lehetnek automatizált vagy manuális ellenőrzések. A tevékenység gyakran a tranzakció állapotának „New” értékről „Validated” vagy „Pending Approval” értékre változásából következtethető ki. | ||
| Miért fontos? A kezdeti adatellenőrzési lépések hatékonyságát méri. Az itt fellépő késések szűk keresztmetszetet okozhatnak a folyamat korábbi szakaszaiban, és növelhetik a későbbi fizetési hibák esélyét. Hol szerezhető be? A fő fizetési tranzakciós tábla állapotváltozásait tartalmazó mezők alapján következtethető ki. Hasonlítsa össze a „Created” állapot és az azt követő „Validated” vagy hasonló állapot időbélyegeit. Rögzítés A fizetési állapot mezőjének változásából következtethető ki, például az „Entered” állapot „Validated” értékre váltásából. Eseménytípus inferred | |||
| Fizetési hiba javítva | Azt a pontot jelöli, amikor a felhasználó kijavít egy korábban észlelt hibát, majd a fizetést újra feldolgozásra küldi. Erre gyakran abból lehet következtetni, hogy a fizetés állapota hibásról normál feldolgozási állapotra vált. | ||
| Miért fontos? Ez a tevékenység lezárja a kivételkezelési ciklust. A „Fizetési hiba észlelve” esemény és e között eltelt idő a hibajavítási ciklusidő, amely a működési hatékonyság egyik fontos mérőszáma. Hol szerezhető be? A „Hiba” állapotból egy feldolgozási állapotba, például „Jóváhagyásra vár” vagy „Ellenőrizve” történő váltásból következtethető ki. Külön felhasználói műveletként is rögzíthetik. Rögzítés A hibás állapotból történő állapotváltásból következtethető ki, ami azt jelzi, hogy a hibát kijavították. Eseménytípus inferred | |||
| Fizetési utasítás elküldve | Azt jelzi, hogy a fizetési utasítást összeállították és továbbították egy külső fizetési hálózatnak, például a SWIFT-nek, az ACH-nak vagy a SEPA-nak. Az ACI rendszerei ezt az átadást kifejezetten naplózzák auditálási és nyomon követési célból. | ||
| Miért fontos? Sok fizetéstípus esetében ez a „visszafordíthatatlan pont”. Nyomon követésével mérhető a belső feldolgozási idő, mielőtt a külső függőségek átvennék a szerepet. Hol szerezhető be? Ez szinte mindig kifejezett eseményként szerepel az ACI tranzakciós vagy üzenetnaplóiban, gyakran a hálózatspecifikus hivatkozási számmal együtt. Rögzítés A rendszer kifejezett naplóbejegyzést hoz létre, amikor elküldi a fizetési üzenetet a külső hálózatnak. Eseménytípus explicit | |||
| Sikertelen fizetés | Végleges állapot, amely azt jelzi, hogy a fizetés helyrehozhatatlan hiba miatt nem teljesíthető. Ez nem azonos a javítható hibával, hanem a folyamat egyértelmű sikertelen lezárását jelenti. | ||
| Miért fontos? Ennek a záró eseménynek a követése szükséges a fizetési hibaarány kiszámításához. A hibák okainak elemzése segíthet javítani az adatminőséget és a folyamat szabályait. Hol szerezhető be? A tranzakciós adatokban szereplő végleges állapotból következtethető ki, például „Sikertelen”, „Törölve” vagy „A bank elutasította”, ha az állapot később már nem változik. Rögzítés A fizetési rekord végleges hibastátuszából következtethető ki. Eseménytípus inferred | |||
Adatkinyerési útmutatók
Lépések
Adatbázis-környezet elérése: SQL Server Management Studio (SSMS) vagy más kompatibilis kliens segítségével csatlakozzon az ACI Postilion Realtime adatbázist tároló SQL Server-példányhoz.
A fő táblák azonosítása: Keresse meg a
post_tran(tranzakciós napló) és apost_tran_cust(egyéni adatokat tartalmazó bővítmény) táblát. Ellenőrizze, hogy rendelkezik-eSELECTjogosultsággal ezekhez az objektumokhoz.Az esetazonosító meghatározása: A lekérdezés a
retrieval_reference_nrmezőt használjaPaymentTransactionIdértékként. Ha a rendszer más egyedi kulcsot használ, például asystem_trace_audit_nrés atransmission_date_timekombinációját, ennek megfelelően módosítsa a lekérdezésben kiválasztott mezőket.Szűrési paraméterek beállítása: Nyissa meg az alábbi lekérdezést. Keresse meg a szkript elején az
@StartDateés@EndDateváltozókat. Állítsa be a kívánt időszakot, például az elmúlt 30–90 napot, hogy a lekérdezés hatékonyan fusson.A tevékenységek logikájának ellenőrzése: A lekérdezés az ISO 8583 üzenettípusokat, például a 0200 és 0210 értéket, valamint a válaszkódokat rendeli hozzá a 14 szükséges process mining tevékenységhez. Ellenőrizze a
CASEutasításokat, és győződjön meg arról, hogy megfelelnek az ACI-felület beállításainak.A lekérdezés futtatása: Futtassa a teljes szkriptet. A lekérdezés
UNION ALLsegítségével egységesíti a különböző tranzakcióállapotokat, és egységes eseménynapló-formátumba rendezi őket.A kimeneti adatok ellenőrzése: Ellenőrizze, hogy szerepelnek-e a szükséges oszlopok:
PaymentTransactionId,ActivityNameésEventTimestamp. Győződjön meg arról, hogy a fontos mezőkben nincsenek váratlanulNULLértékek.Adatok exportálása: Kattintson a jobb gombbal az SSMS eredménytáblájára, és mentse az adatokat CSV-fájlként, például
ACI_Payments_EventLog.csvnéven.Formázás a ProcessMindhoz: Nyissa meg a CSV-fájlt, és ellenőrizze, hogy az
EventTimestampformátuma szabványos-e (YYYY-MM-DD HH:MM:SS), aPaymentAmountpedig csak számértékeket tartalmaz-e.Feltöltés: Importálja az ellenőrzött CSV-fájlt a ProcessMindba, és rendelje hozzá az oszlopokat az Ügyazonosító, a Tevékenység és az Időbélyeg mezőkhöz.
Konfiguráció
- Dátumtartomány: Az ACI
post_trantáblái gyorsan növekednek. Erősen ajánlott a kinyerést gördülő, 3 hónapos időszakra korlátozni, vagy partícióváltást alkalmazni, ha erre van lehetőség. - Válaszkódok: A lekérdezés feltételezi, hogy az
rsp_code = '00'sikeres tranzakciót jelez. Ha az intézménye más kódokat használ a jóváhagyás vagy siker jelzésére (például '08' vagy '10'), módosítsa a szűrőket. - Üzenettípusok (ISO 8583): A szkript a szabványos üzenettípusokra épül (0100/0200 a kérésekhez, 0210 a válaszokhoz). A
source_node_namebeállításban megadott egyéni üzenettípusok módosítást igényelhetnek. - Rendszerteljesítmény: A lekérdezés
NOLOCKtippeket használ, hogy ne akadályozza az éles tranzakciófeldolgozást. Éles környezetben ne távolítsa el ezeket. - Pénznemek: Az összegek nyers értékként kerülnek ki. Ha az elemzéshez több pénznem egységesítése szükséges, használja a
tran_currency_codemezőt.
Példa-lekérdezés 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; Készen áll a kezdésre?
Használja ezt a sablont útmutatóként a fizetési folyamat adatainak kinyeréséhez. Tárja fel az értékes összefüggéseket, és tegye hatékonyabbá pénzügyi munkafolyamatait még ma.
Tegye gördülékenyebbé a fizetési folyamatot, kezdje el most a próbaverziót
Szüntesse meg a fizetési kivételeket, és érjen el 98%-os automatikus feldolgozási arányt.
Nincs szükség bankkártyára, a beállítás percek alatt elvégezhető