> Folyamatos folyamatfejlesztés > Fizetési folyamatok > Fiserv > Adatsablon

Fizetésfeldolgozási adatsablon

Name: Fizetési folyamatok process mining adatsablon
Creator: ProcessMind
License: https://creativecommons.org/licenses/by/4.0/

Fiserv

← Vissza a folyamatfejlesztési útmutatóhoz

A fizetésfeldolgozás attribútumai(19) A fizetésfeldolgozás tevékenységei(13) Adatkinyerési útmutatók(1)

Fizetésfeldolgozási adatsablon

Ez a sablon keretet ad ahhoz, hogy a Fiserv-adatait process mininghez és elemzéshez megfelelő formátumba rendezze. Bemutatja azokat az alapvető attribútumokat és tevékenységeket, amelyekkel átláthatóvá teheti az elszámolási és egyeztetési ciklusokat. Az útmutatót követve olyan eseménynaplót készíthet, amely feltárja a pénzügyi működés hatékonysági problémáit és a megfelelési kockázatokat.

A fizetéselemzéshez javasolt attribútumok
Követendő folyamatmérföldkövek
Technikai útmutató a Fiserv-adatok kinyeréséhez

Most ismerkedik az eseménynaplókkal? Tudja meg, hogyan készíthet process mining eseménynaplót.

Sablon letöltése

A fizetésfeldolgozás attribútumai

Ezek a javasolt adatmezők biztosítják az eseménynapló elemzéséhez szükséges hátteret, így a teljes fizetési folyamatot átfogóan vizsgálhatja.

5 Kötelező 9 Javasolt 5 Nem kötelező

	Név	Leírás
	Esemény időbélyege EventTimestamp	A tevékenység pontos dátuma és időpontja.
Leírás Ez az attribútum rögzíti az esemény pontos időpontját. Minden időbeli elemzés alapja, beleértve a ciklusidő, az átfutási idő és a szűk keresztmetszetek meghatározását. A dashboardokon ezekből az adatokból számítható ki az egyes lépések közötti idő, például a „Fizetési kérelem létrehozva” és a „Fizetés engedélyezve” esemény közötti időtartam. A gyors egymásutánban bekövetkező események pontos sorrendjének megállapításához nagy pontosságú időbélyegek szükségesek. Miért fontos? Az események sorrendbe állításához és a folyamat teljesítési idejének kiszámításához szükséges. Hol szerezhető be? Naplók vagy a tranzakciófrissítések időbélyegét tároló oszlopok. Példák 2023-10-15T08:30:00Z2023-10-15T09:15:22Z2023-10-16T14:00:00Z2023-10-17T10:00:00Z
	Fizetési tranzakcióazonosító PaymentTransactionId	Az adott fizetési utasítás vagy tranzakció egyedi azonosítója.
Leírás Ez az attribútum a fizetés teljes életciklusán belüli összes tevékenység összekapcsolására szolgáló központi azonosító. Segítségével az elemzők a kezdeti kérelemtől az ellenőrzésen és jóváhagyáson át a végső elszámolásig vagy törlésig követhetik az ügyet. A Fiserv rendszereiben ez jellemzően a tranzakciós előzményeket tároló táblák elsődleges kulcsa. Nélkülözhetetlen a folyamat rekonstruálásához és annak biztosításához, hogy az egymástól távoli események, például a jóváhagyás után napokkal történő elszámolás, ugyanahhoz az üzleti objektumhoz kapcsolódjanak. Miért fontos? Ez az alapvető Case ID, amely az eseményeket folyamatpéldányokba rendezi. Hol szerezhető be? A Transaction vagy Payment Header táblákról a Fiserv dokumentációjában tájékozódjon. Példák TRX-99823101PMT-2023-88421002938475CHK-5512WIRE-US-9921
	Tevékenység neve ActivityName	A fizetési folyamatban bekövetkezett esemény vagy állapotváltozás.
Leírás Ez az attribútum írja le a végrehajtott lépést, például a „Fizetési kérelem létrehozva” vagy a „Fizetés elszámolva” eseményt. Meghatározza a folyamattérkép csomópontjait, és segít megérteni a lépések sorrendjét. Az egyes tevékenységek elemzésével a szervezet megjelenítheti a munkafolyamatot, felismerheti a kihagyott lépéseket, és feltárhatja azokat az előírásoknak nem megfelelő útvonalakat, ahol megkerülték a kötelező ellenőrzéseket vagy jóváhagyásokat. Miért fontos? Meghatározza a folyamat idővonalát alkotó eseményeket. Hol szerezhető be? Tranzakciós előzményeket vagy állapotváltozásokat rögzítő naplótáblák. Példák Fizetési kérelem létrehozvaFizetés engedélyezveFizetési hiba észlelveFizetés elszámolvaFizetés törölve
	Forrásrendszer SourceSystem	Annak a rendszernek a neve, ahonnan az adat származik.
Leírás Azonosítja azt a Fiserv-modult vagy külső rendszert, amely az eseményt létrehozta. Ez különösen összetett rendszertáj esetén hasznos, amikor a fizetés egy front-end csatornán indul, majd egy back-end alapbanki rendszerben kerül elszámolásra. Az elemzők a forrásrendszer szerint szűrhetik a folyamatnézetet, így az elemzést egy adott technikai környezetre vagy integrációs pontra összpontosíthatják. Miért fontos? Technikai hátteret és adatleszármazást mutat. Hol szerezhető be? Az adatkinyerés során rögzített érték vagy rendszer-metaadat. Példák Fiserv PremierFiserv SignatureFiserv DNAFiserv Enterprise Payments Platform
	Utolsó adatfrissítés LastDataUpdate	Az időbélyeg, amely megmutatja, mikor nyerték ki vagy frissítették utoljára a rekordot.
Leírás Jelzi, mennyire frissek az elemzéshez használt adatok. Ebből állapítható meg, hogy a dashboardok a valós idejű működést vagy egy korábbi állapotot mutatnak-e. Segít megbízni a megjelenített mutatókban, és elkerülni, hogy elavult adatok alapján szülessenek döntések, különösen a határidők betartásának vagy az aktuális szűk keresztmetszeteknek a figyelésekor. Miért fontos? Biztosítja az adatok naprakészségét és megbízhatóságát. Hol szerezhető be? A rendszeridő az ETL futtatásakor. Példák 2023-10-27T12:00:00Z2023-10-28T06:00:00Z
	Feldolgozó felhasználó ProcessingUser	A tevékenységért felelős felhasználó vagy rendszerügynök azonosítója.
Leírás Megmutatja, ki hajtotta végre az adott műveletet, legyen az emberi jóváhagyó vagy automatizált rendszer. Ezek az adatok táplálják az Error Resolution Cycle Efficiency és az Approval Authority Throughput dashboardokat. A felhasználók tevékenységének nyomon követésével az elemzők felismerhetik, ha valakinek a magas hibaarány miatt képzésre van szüksége, vagy ha egyes jóváhagyók túl sok kérést kapnak, és emiatt szűk keresztmetszet alakul ki. Miért fontos? Támogatja az erőforrások elemzését és a szűk keresztmetszetek feltárását. Hol szerezhető be? Naplók, User ID oszlop. Példák jdoeSYSTEM_BATCHmsmith_approverAPI_USER
	Fizetés összege PaymentAmount	A fizetési tranzakció pénzösszege.
Leírás Ez az attribútum a fizetés pénzügyi értékét mutatja. Az elemzés egyik fő dimenziója, amely alapján elkülöníthetők a nagy értékű, stratégiai jelentőségű fizetések a kisebb összegű, rutinszerű tranzakcióktól. A Duplicate Payment Detection View nézetben nélkülözhetetlen: az azonos összegek és a fizetőre, illetve kedvezményezettre vonatkozó adatok együtt jelezhetik a lehetséges hibákat. A jóváhagyási jogosultságok elemzését is támogatja, mivel a nagyobb összegek gyakran más munkafolyamatot indítanak el. Miért fontos? Nélkülözhetetlen a pénzügyi kockázatok elemzéséhez és a duplikált tranzakciók felismeréséhez. Hol szerezhető be? Tranzakciós fejlécet tartalmazó tábla, Amount oszlop. Példák 150.0025000.5010.991000000.00
	Fizetési határidő PaymentDueDate	Az a dátum, ameddig a fizetést fel kell dolgozni.
Leírás A fizetés teljesítésének céldátuma. A Processing Cutoff Compliance Monitor ennek alapján jelöli meg a késés kockázatának kitett tranzakciókat. A „Fizetés elszámolva” esemény időbélyegének összevetése ezzel az attribútummal lehetővé teszi a határidőre teljesített fizetések mérését, és segít megőrizni a kedvezményezettek bizalmát. Miért fontos? Viszonyítási alap az SLA betartásának méréséhez. Hol szerezhető be? Fizetési utasítás adatai. Példák 2023-11-012023-11-15
	Fizetési mód PaymentMethod	A fizetés végrehajtásához használt mód, például Wire vagy ACH.
Leírás A tranzakciót a feldolgozási csatorna szerint sorolja be. Ez alapvető az Authorization Cycle Time Analysis elemzéshez, mivel az egyes fizetési módok feldolgozási rendje és szolgáltatási szintre vonatkozó megállapodásai jelentősen eltérhetnek. A folyamatváltozatok fizetési mód szerinti elemzésével megállapítható, hogy a késedelmek egy adott csatornára, például a nemzetközi Wire-átutalásokra jellemzők-e, vagy a szervezet egészét érintik. Miért fontos? A használt infrastruktúra szerint bontja fel a folyamatokat. Hol szerezhető be? Tranzakciótípust vagy fizetési eszközt jelölő kódot tartalmazó oszlop. Példák Wire-átutalásACHCsekkRTPBelső átutalás
	Fizető számlaszáma PayerAccountNumber	A számlaszám, amelyről az összeget levonják.
Leírás Azonosítja a fizetés forrásszámláját. A Duplicate Payment Detection View egyik fontos adata. A kedvezményezettel, az összeggel és az időponttal együtt egyedi azonosítót alkot, amely segít kiszűrni a véletlen dupla fizetéseket. A forrásszámla szerinti fizetési volumen elemzésére is alkalmas, így azonosíthatók a legaktívabb belső portfóliók. Miért fontos? Nélkülözhetetlen a duplikált tranzakciók felismeréséhez és a csalások elemzéséhez. Hol szerezhető be? Tranzakciós adatok, Debit Account oszlop. Példák 123456789987654321ACC-001-992
	Hibakód ErrorCode	A fizetés ellenőrzésének sikertelenségekor létrejövő konkrét kód.
Leírás Rögzíti a „Fizetési hiba azonosítva” tevékenységhez kapcsolódó technikai vagy üzleti hibakódot. Ez az attribútum a Validation Error and Rework Tracker alapja. Az egyes hibakódok gyakoriságának összesítésével a szervezet feltárhatja az adatok minőségét érintő rendszerszintű problémákat, például az „Érvénytelen banki irányítószám” hibát, és célzottan javíthatja az ellenőrzési szabályokat vagy a felhasználók képzését. Miért fontos? Segít feltárni az ismételt munkavégzés kiváltó okait. Hol szerezhető be? Hibanaplók vagy a tranzakció állapotának részletei. Példák E-101INV_ACCNSF_ERRAUTH_FAIL
	Kedvezményezett számlaszáma PayeeAccountNumber	A számlaszám, amelyre az összeget jóváírják.
Leírás Azonosítja a célszámlát. A fizető számlájához hasonlóan ez is fontos a Duplicate Payment Detection View nézetben, mert segít a megfelelő kedvezményezetti kapcsolatok vizsgálatában. A határidők betartásának figyelésekor a kedvezményezett ismeretében előnyben részesíthetők a stratégiai beszállítók vagy a kritikus elszámolások, amelyek nem maradhatnak el. Miért fontos? Nélkülözhetetlen a duplikált tranzakciók felismeréséhez és a kedvezményezettek elemzéséhez. Hol szerezhető be? Tranzakciós adatok, Credit Account vagy Beneficiary oszlop. Példák 555000111222333444BEN-882-11
	Pénznemkód CurrencyCode	A fizetés összegének ISO szerinti pénznemkódja.
Leírás Megadja, milyen pénznemben történik a fizetés, például USD-ben vagy EUR-ban. Ez az attribútum fontos a Currency and Method Volume Trends dashboardhoz, amelyen a szervezet nyomon követheti a különböző devizáknak való kitettségét. A globális jelentésekben az összegek egységesítésére is használható, és segít elkerülni, hogy a duplikációellenőrzés azonos számértékű, de eltérő pénznemű tranzakciókat tévesen megjelöljön. Miért fontos? Több pénznemben történő feldolgozás elemzéséhez szükséges. Hol szerezhető be? Tranzakciós fejlécet tartalmazó tábla, Currency oszlop. Példák USDEURGBPCADJPY
	STP-e IsStraightThroughProcessing	Jelzi, hogy a fizetéshez szükség volt-e kézi beavatkozásra.
Leírás Számított logikai attribútum, amely akkor igaz, ha az ügyben nem szerepel „Fizetési hiba azonosítva”, „Fizetési hiba megoldva” vagy kézi „Fizetés jóváhagyva” lépés, a meghatározástól függően. Közvetlenül támogatja a Straight Through Processing Rate KPI-t. A folyamat két csoportra bontható: teljesen automatizált, illetve emberi beavatkozást igénylő esetekre. Így jól láthatóvá válik az automatizálási lehetőség. Miért fontos? A folyamat hatékonyságának és az automatizálás eredményességének alapmutatója. Hol szerezhető be? Az adatátalakítás során számítva. Példák truefalse
	Elmaradt a határidőről IsCutoffMissed	Jelzi, hogy a fizetést a bank napi határideje után küldték-e el.
Leírás Számított logikai érték, amely összeveti a „Fizetési utasítás elküldve” esemény időpontját az adott pénznemhez és fizetési módhoz tartozó napi határidővel. A Cutoff Adherence Rate KPI kiszámítását támogatja. Az elmaradt határidők feltárása segít megkeresni a késedelmek kiváltó okát, legyen szó késői indításról vagy lassú belső feldolgozásról. Miért fontos? Nélkülözhetetlen a működési megfelelés és a likviditás kezeléséhez. Hol szerezhető be? Az EventTimestamp és a Cutoff Reference tábla összevetésével számítva. Példák truefalse
	Ismételt munka-e IsRework	Jelzi, hogy az adott tevékenység része-e egy ismételt munkavégzési ciklusnak.
Leírás Logikai jelző, amely megjelöli a hiba azonosítása és megoldása között végrehajtott, illetve az ismétlődő tevékenységeket. A Payment Validation Rework Rate KPI kiszámítását támogatja. Az elemzők úgy szűrhetik a folyamattérképet, hogy csak a problémamentes folyamatútvonalat lássák, vagy éppen az ismételt munkavégzés útvonalára összpontosítsanak a hibák okainak feltárásához. Miért fontos? Elkülöníti az értéket teremtő munkát a javítási feladatoktól. Hol szerezhető be? A folyamat ismétlődő ciklusai alapján számítva. Példák truefalse
	Jóváhagyási szint ApprovalLevel	A fizetés engedélyezéséhez szükséges vagy ténylegesen alkalmazott hierarchiaszint.
Leírás Megadja a „Fizetés jóváhagyva” tevékenységhez tartozó beosztási vagy jogosultsági szintet. Az Approval Authority Throughput dashboardon elemezhető, hogy a magasabb szintű jóváhagyók miatt kialakul-e szűk keresztmetszet. A fizetések szintek szerinti megoszlásának, például az 1. és a 3. szintnek az ismerete segít optimalizálni a jogosultságok delegálását. Miért fontos? A jóváhagyási folyamat szűk keresztmetszeteit hierarchiaszint szerint bontja fel. Hol szerezhető be? Felhasználói szerepköröket vagy jóváhagyási munkafolyamatokat tartalmazó táblák. Példák 1. szintVezetőIgazgatóCFO
	Kedvezményezett bankja BeneficiaryBank	A fogadó bank neve vagy azonosítója.
Leírás Azonosítja a fizetést fogadó pénzintézetet. Hasznos az elszámolási késedelmek elemzéséhez, mivel az egyes fogadó bankok feldolgozási sebessége és integrációja eltérhet. További dimenziót ad a Settlement to Reconciliation Gap dashboardhoz, és megmutatja, hogy a késedelem külső, vagyis egy adott bankhoz köthető, vagy belső eredetű. Miért fontos? Külső függőségek elemzése. Hol szerezhető be? Tranzakciós adatok, Bank ID vagy Name oszlop. Példák ChaseBank of AmericaWells FargoCitibank
	Szervezeti egység BusinessUnit	A fizetést kezdeményező részleg vagy szervezeti egység.
Leírás A fizetést a kiadásért felelős szervezeti egység szerint sorolja be. Segít a költségek felosztásában, és megmutatja, hogy a szervezet mely részein keletkezik a legtöbb kézi javítás vagy hiba. A Payment Path Compliance Audit elemzést is támogatja, mert ellenőrizhető vele, hogy az egyes egységek betartják-e a rájuk vonatkozó szabályozási vagy belső kontrollkövetelményeket. Miért fontos? Szervezeti hátteret ad a teljesítmény értékeléséhez. Hol szerezhető be? Költséghely-hozzárendelés vagy részlegkód. Példák Lakossági banki szolgáltatásokVállalati hitelezésVagyonkezelésMűködés

Kötelező Javasolt Nem kötelező

A fizetésfeldolgozás tevékenységei

Rögzítse ezeket az alapvető folyamatlépéseket és mérföldköveket az eseménynaplóban, hogy pontosan feltárhassa és fejleszthesse fizetési munkafolyamatait.

5 Javasolt 8 Nem kötelező

	Tevékenység	Leírás
	Fizetés egyeztetve	A tranzakció belső egyeztetése a bankszámlakivonatokkal vagy elszámolási fájlokkal. Ezzel lezárul a könyvelési folyamat.
Miért fontos? A „Settlement to Reconciliation Gap” méréséhez szükséges. Segít biztosítani a pénzügyi könyvek pontos zárását. Hol szerezhető be? Az egyeztetési modul naplói, ahol az állapot „Egyeztetve” vagy „Összepárosítva” értékre változik. Rögzítés Az egyezés megtalálásakor naplózva Eseménytípus explicit
	Fizetés elszámolva	A pénzmozgás lezárul, az összeget pedig lekönyvelik a főkönyvbe. A bank szempontjából ez jelenti a tranzakció pénzügyi teljesítését.
Miért fontos? A „Straight Through Processing Rate” KPI elsődleges végpontja. Azt jelzi, hogy a pénz ténylegesen megérkezett. Hol szerezhető be? A tranzakció „Könyvelve” állapota vagy a főkönyvi „Könyvelés dátuma” időbélyeg megléte. Rögzítés A főkönyvi könyveléskor naplózva Eseménytípus explicit
	Fizetés jóváhagyva	Manuális vagy automatizált döntés arról, hogy a fizetés az engedélyezési értékhatárok alapján folytatódhat-e. Akkor kerül rögzítésre, amikor egy jogosult felhasználó vagy rendszerbeli szabály módosítja a jóváhagyási jelzőt.
Miért fontos? Az „Authorization Cycle Time Analysis” elemzés egyik alapadata. Az itt jelentkező késedelmek a jóváhagyási lánc szűk keresztmetszeteire utalnak. Hol szerezhető be? Az ellenőrzési naplóban látható felhasználói művelet, amely a „Pending Approval” állapotot „Approved” állapotra változtatja. Rögzítés A jóváhagyási művelet végrehajtásakor kerül a naplóba Eseménytípus explicit
	Fizetési kérelem létrehozva	A fizetési utasítás első rögzítése a Fiserv rendszerében. Az esemény akkor kerül a naplóba, amikor egy felhasználó vagy külső rendszer API-n vagy felületen keresztül elindítja a tranzakciót.
Miért fontos? Ez jelöli a folyamat idővonalának kezdetét. Szükséges a teljes átfutási idő kiszámításához és a beérkezésnél jelentkező szűk keresztmetszetek felismeréséhez. Hol szerezhető be? A tranzakciós előzményeket tartalmazó tábla létrehozásának időbélyege. Keresse meg az adott Payment Transaction ID-hoz tartozó legkorábbi rekordot. Rögzítés A tranzakciós rekord rögzítésekor kerül a naplóba Eseménytípus explicit
	Fizetési utasítás elküldve	A fizetési fájl, például ACH-köteg vagy Wire-üzenet továbbítása a külső hálózatnak vagy elszámolóháznak. Ez fontos átadási pont.
Miért fontos? A „Processing Cutoff Compliance Monitor” működéséhez elengedhetetlen. Segít biztosítani, hogy a szervezet betartsa a napi banki határidőket. Hol szerezhető be? Kötegelt feldolgozási naplók vagy fájlgenerálási időbélyegek. Gyakori bejegyzések: „Köteg létrehozva” vagy „Fájl továbbítva”. Rögzítés A kötegfájl létrehozásakor naplózva Eseménytípus explicit
	Fizetés engedélyezve	A végső belső visszaigazolás arról, hogy rendelkezésre áll a pénz, és a tranzakció végrehajtható. Ez történhet a jóváhagyással egy időben vagy külön rendszerellenőrzésként.
Miért fontos? Megkülönbözteti a vezetői jóváhagyást a rendszer szintű engedélyezéstől. Fontos az „Approval Authority Throughput” dashboardhoz. Hol szerezhető be? Állapotváltozás, amely az „Engedélyezve” vagy „Könyvelésre kész” állapotot jelzi. Rögzítés Hasonlítsa össze az állapotmezőt a változás előtt és után Eseménytípus inferred
	Fizetés törölve	A fizetési folyamat leállítása az elszámolás előtt, felhasználói kezdeményezésre vagy rendszerbeli szabály alapján. A további feldolgozás megszűnik.
Miért fontos? Feltárja a felesleges munkát és a félbehagyott ügyeket. A jóváhagyás utáni magas törlési arány a folyamat hiányosságaira utalhat. Hol szerezhető be? Állapotváltozás „Törölve”, „Érvénytelenítve” vagy „Leállítva” értékre. Rögzítés A „Törölve” állapotra váltáskor naplózva Eseménytípus explicit
	Fizetés ütemezve	Akkor fordul elő, ha a fizetést jóváhagyták, de egy későbbi teljesítési dátumig visszatartják. A rendszer sorba állítja a tranzakciót, amíg meg nem nyílik a feldolgozási időablak.
Miért fontos? Segít értelmezni a folyamatban töltött várakozási időt. Megkülönbözteti a szűk keresztmetszet okozta késedelmet a fizetési határnapig tartó szándékos várakozástól. Hol szerezhető be? A „Rögzítés dátuma” és a „Teljesítés dátuma” összevetése. Ha a teljesítés dátuma a jövőre esik, ez az állapot aktív. Rögzítés Az X és Y mező összehasonlításából származik Eseménytípus calculated
	Fizetés visszaigazolva	Pozitív visszaigazolás (ACK) érkezik a külső hálózattól vagy átjárótól. Ez megerősíti, hogy a következő fél érvényesen megkapta az utasítást.
Miért fontos? Ellenőrzi, hogy az „Utasítás elküldve” esemény sikeres volt-e. Az itt jelentkező hiányosságok hálózati kapcsolati vagy külső formátumproblémára utalhatnak. Hol szerezhető be? Bejövő fájlok feldolgozási naplói vagy a beérkezést visszaigazoló API-válaszkódok. Rögzítés Az ACK beérkezésekor naplózva Eseménytípus explicit
	Fizetési adatok ellenőrizve	A rendszer ellenőrzi a számlaszámokat, az útválasztási számokat és a formátum megfelelőségét. Az esemény általában abból állapítható meg, hogy a tranzakció hiba nélkül, sikeresen lép át a beérkezett állapotból függőben lévő vagy jóváhagyott állapotba.
Miért fontos? Azt jelzi, hogy a tranzakció átjutott az első automatizált ellenőrzési ponton. Az itt jelentkező hiba adatminőségi problémára utal, nem likviditási vagy jóváhagyási gondra. Hol szerezhető be? Rövid időn belüli állapotváltásból állapítható meg: „Received” állapotból „Pending” vagy „Ready” állapotba. Rögzítés Hasonlítsa össze az állapotmezőt a változás előtt és után Eseménytípus inferred
	Fizetési értesítés elküldve	A rendszer e-mailben vagy SMS-ben értesíti a fizetőt vagy a kedvezményezettet a tranzakcióról. Ez átláthatóbbá teszi a folyamatot az ügyfél számára.
Miért fontos? A „Notification Speed and Responsiveness” mérését támogatja. Az elszámolás utáni hosszú várakozás csökkenti az ügyfelek bizalmát. Hol szerezhető be? A tranzakcióazonosítóhoz kapcsolódó kommunikációs naplók vagy ügyfélkapcsolati előzményeket tartalmazó táblák. Rögzítés Az e-mail vagy SMS elküldésekor naplózva Eseménytípus explicit
	Fizetési hiba észlelve	Azt az időpontot rögzíti, amikor a tranzakció sikertelen állapotot vagy kivételkódot kap. Ez akkor történik, ha az ellenőrzési szabályok nem teljesülnek, vagy egy külső ellenőrzés elutasító választ ad.
Miért fontos? A „Validation Error and Rework Tracker” dashboard egyik alapadata. A magas értékek a folyamat korábbi szakaszaiban jelentkező adatminőségi problémákra utalnak. Hol szerezhető be? A tranzakció állapotmezője kivételkódra változik, például „Invalid”, „Hold” vagy „Error” értékre. Rögzítés Akkor kerül a naplóba, amikor az állapot Error értékre változik Eseménytípus explicit
	Fizetési hiba megoldva	Egy korábban hibás tranzakció javítását jelöli. Akkor állapítható meg, amikor a tranzakció hibás állapotból feldolgozás alatt vagy érvényes állapotba kerül.
Miért fontos? A „Mean Time to Resolve Payment Errors” mutató kiszámításához szükséges. Segít mérni a működési csapat hatékonyságát. Hol szerezhető be? Akkor állapítható meg, amikor a tranzakció állapota hibakódról normál feldolgozási kódra változik. Rögzítés Hasonlítsa össze az állapotmezőt a változás előtt és után Eseménytípus inferred

Javasolt Nem kötelező

Adatkinyerési útmutatók

Adatok kinyerése a Fiservből

Lépések

1. Előfeltételek beállítása

Ellenőrizze, hogy hozzáfér-e a Fiserv Commerce Hub fejlesztői portáljához. Hozzon létre API-kulcsot és API-titkos kulcsot, más néven Client ID-t és Client Secretet, amelyekkel elérheti a Transaction Inquiry vagy a Search API-t. Ha a Fiserv-környezet IP-címkorlátozást alkalmaz, ellenőrizze, hogy az IP-címe szerepel-e az engedélyezőlistán.

2. Környezet beállítása

Telepítse a Python 3.8-as vagy újabb verzióját a kinyerést végző kiszolgálóra vagy a helyi gépre. Szüksége lesz a requests és a pandas könyvtárra. Ezeket a pip install requests pandas paranccsal telepítheti. Hozzon létre egy munkakönyvtárat a szkriptnek és a kimeneti fájloknak.

3. A szkript beállítása

Töltse le a mellékelt Python-szkriptet a munkakönyvtárba. Nyissa meg, és frissítse a tetején található konfigurációs részt. Adja meg a saját API_KEY, API_SECRET és BASE_URL értékét. Teszteléshez használja a tesztkörnyezet URL-jét, a végleges futtatáshoz pedig az éles környezetét. Állítsa be a START_DATE és END_DATE értékét a kívánt process mining időszaknak megfelelően.

4. A hitelesítés beállítása

A szkript segédosztálya kezeli a Fiserv sajátos hitelesítési követelményeit. Ez általában HMAC-aláírás létrehozását jelenti az API-titkos kulcs, az időbélyeg és a kérés törzse alapján. Ne módosítsa az aláírás létrehozásának logikáját, kivéve, ha az Ön Fiserv-rendszere más szabványt, például OAuth2 bearer tokent használ.

5. Az adatok feldolgozásának megértése

A szkript tranzakciókat kér le az API-tól. Az API általában egy tranzakciós objektum pillanatképét adja vissza, amely több időbélyeget is tartalmazhat, például a beküldés, a jóváhagyás és a teljesítés idejét. A szkript feldolgozza ezt az egyetlen JSON-objektumot, majd több sorra, vagyis eseményre bontja az eseménynaplóhoz. Például egy beküldési és egy teljesítési időbélyeget tartalmazó JSON-rekord legalább két külön sort eredményez a CSV-fájlban.

6. Lapozás kezelése

A szkript ciklussal kezeli a lapozást. A Fiserv API-k válaszonként korlátozzák a rekordok számát, gyakran 50 vagy 100 rekordra. A szkript automatikusan lekéri a következő oldalt, amíg a teljes időszak összes tranzakcióját meg nem kapja. Nagy adatmennyiségnél a folyamat időbe telhet, ezért gondoskodjon stabil internetkapcsolatról.

7. Futtatás

Futtassa a szkriptet a parancssorból: python fiserv_extraction.py. A konzolon megjelenik a folyamat állapota, többek között a feldolgozott oldalak és a lekért tranzakciók száma. Figyelje a HTTP 401 (Unauthorized) és 429 (Rate Limit) hibákat.

8. A kimenet ellenőrzése

A futás befejezése után keresse meg a könyvtárban a fiserv_event_log.csv fájlt. Nyissa meg, és ellenőrizze, hogy az ActivityName oszlopban szerepel-e a 13 szükséges tevékenység, valamint hogy az EventTimestamp mező formátuma megfelelő-e.

9. Utófeldolgozás (nem kötelező)

Ha módosítani kell az időzónát, például UTC-ről helyi időre kell váltani, módosítsa a szkript pandas-átalakítási részét, vagy végezze el az átalakítást a ProcessMindban, a feltöltés után.

10. Feltöltés a ProcessMindba

Importálja a CSV-fájlt a ProcessMindba. A PaymentTransactionId mezőt rendelje az Ügyazonosítóhoz, az ActivityName mezőt a Tevékenységhez, az EventTimestamp mezőt pedig az Időbélyeghez. A numerikus oszlopokat, például a PaymentAmount mezőt, attribútumként állítsa be.

Konfiguráció

API-hitelesítő adatok: API Key és Secret/Shared Secret szükséges. Ellenőrizze, hogy ezek olvasási jogosultságot adnak-e a tranzakciós jelentések végpontjaihoz.
Alap URL: Éles használathoz állítsa be a https://api.commerce.fiserv.com címet, teszteléshez pedig a bevezetés során megadott tanúsítványos vagy tesztkörnyezeti URL-t.
Dátumtartomány: Az API-adatmennyiségek miatt 30–90 napnyi adat kinyerése ajánlott. Korábbi adatok betöltésekor havonta futtassa a szkriptet.
Oldalméret: A memóriahasználat és a hálózati terhelés egyensúlyához hívásonként 100 rekordra van beállítva.
Időzóna: Az API UTC-időbélyegeket ad vissza. A szkript megőrzi ezt a formátumot, hogy az adatok régiók között is egységesek legyenek.
Újrapróbálkozás: A szkript alapvető újrapróbálkozási mechanizmust tartalmaz az időszakos hálózati időtúllépések kezelésére (HTTP 500/502/503).

Példa-lekérdezés python

import requests
import json
import time
import hmac
import hashlib
import base64
import uuid
import pandas as pd
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># CONFIGURATION
class=class="hl-string">"hl-comment"># ==========================================
API_KEY = class="hl-string">"YOUR_API_KEY"
API_SECRET = class="hl-string">"YOUR_API_SECRET"
BASE_URL = class="hl-string">"https://cert.api.fiservapps.com"  class=class="hl-string">"hl-comment"># Update to Production URL as needed
ENDPOINT = class="hl-string">"/ch/payments/v1/transaction-inquiry"
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-01-31"
PAGE_SIZE = 50
OUTPUT_FILE = class="hl-string">"fiserv_event_log.csv"

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># AUTHENTICATION HELPER
class=class="hl-string">"hl-comment"># ==========================================
def generate_headers(payload):
    class=class="hl-string">"hl-comment"># Fiserv Commerce Hub typically requires HMAC auth
    class=class="hl-string">"hl-comment"># This is a standard implementation pattern
    client_request_id = str(uuid.uuid4())
    timestamp = str(int(time.time() * 1000))
    
    class=class="hl-string">"hl-comment"># specific signature construction depends on Fiserv documentation version
    class=class="hl-string">"hl-comment"># standard pattern: apiKey + reqId + timestamp + payload
    raw_signature = API_KEY + client_request_id + timestamp + payload
    
    hmac_obj = hmac.new(
        API_SECRET.encode(class="hl-string">'utf-8'),
        raw_signature.encode(class="hl-string">'utf-8'),
        hashlib.sha256
    )
    message_signature = base64.b64encode(hmac_obj.digest()).decode(class="hl-string">'utf-8')
    
    return {
        class="hl-string">"Content-Type": class="hl-string">"application/json",
        class="hl-string">"Client-Request-Id": client_request_id,
        class="hl-string">"Api-Key": API_KEY,
        class="hl-string">"Timestamp": timestamp,
        class="hl-string">"Message-Signature": message_signature
    }

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># PARSING LOGIC (UNPIVOTING EVENTS)
class=class="hl-string">"hl-comment"># ==========================================
def extract_events_from_transaction(tx):
    events = []
    
    class=class="hl-string">"hl-comment"># Base Attributes
    case_id = tx.get(class="hl-string">"transactionId", class="hl-string">"")
    amount = tx.get(class="hl-string">"amount", {}).get(class="hl-string">"total", 0.0)
    currency = tx.get(class="hl-string">"amount", {}).get(class="hl-string">"currency", class="hl-string">"USD")
    method = tx.get(class="hl-string">"paymentMethod", {}).get(class="hl-string">"type", class="hl-string">"Unknown")
    payer_acc = tx.get(class="hl-string">"paymentMethod", {}).get(class="hl-string">"maskedAccountNumber", class="hl-string">"")
    class=class="hl-string">"hl-comment"># Identifying common attributes
    base_data = {
        class="hl-string">"PaymentTransactionId": case_id,
        class="hl-string">"SourceSystem": class="hl-string">"Fiserv Commerce Hub",
        class="hl-string">"LastDataUpdate": datetime.utcnow().isoformat(),
        class="hl-string">"PaymentAmount": amount,
        class="hl-string">"CurrencyCode": currency,
        class="hl-string">"PaymentMethod": method,
        class="hl-string">"PayerAccountNumber": payer_acc,
        class="hl-string">"PayeeAccountNumber": class="hl-string">"MerchantAccount", class=class="hl-string">"hl-comment"># Placeholder
        class="hl-string">"ErrorCode": tx.get(class="hl-string">"processorResponseDetails", {}).get(class="hl-string">"responseCode", class="hl-string">""),
        class="hl-string">"IsStraightThroughProcessing": class="hl-string">"True" class=class="hl-string">"hl-comment"># Default assumption unless error found
    }

    class=class="hl-string">"hl-comment"># Helper to append event
    def add_event(activity, timestamp_str, specific_attrs={}):
        if timestamp_str:
            row = base_data.copy()
            row.update({
                class="hl-string">"ActivityName": activity,
                class="hl-string">"EventTimestamp": timestamp_str
            })
            row.update(specific_attrs)
            events.append(row)

    class=class="hl-string">"hl-comment"># 1. Payment Request Created (Submission Time)
    submission_time = tx.get(class="hl-string">"submissionTime")
    add_event(class="hl-string">"Payment Request Created", submission_time)

    class=class="hl-string">"hl-comment"># 2. Payment Details Validated (Inferred: slightly after submission if no immediate 400 error)
    class=class="hl-string">"hl-comment"># We infer this exists if the transaction exists and has a submission time
    if submission_time:
        class=class="hl-string">"hl-comment"># Infer validation happened 1 second after submission
        val_time = (datetime.fromisoformat(submission_time.replace(class="hl-string">'Z', class="hl-string">'+00:00')) + timedelta(seconds=1)).isoformat()
        add_event(class="hl-string">"Payment Details Validated", val_time)

    class=class="hl-string">"hl-comment"># 3. Payment Error Identified / 4. Resolved
    status = tx.get(class="hl-string">"transactionStatus", class="hl-string">"")
    if status == class="hl-string">"FAILED":
        fail_time = tx.get(class="hl-string">"processorResponseDetails", {}).get(class="hl-string">"responseTimestamp", submission_time)
        add_event(class="hl-string">"Payment Error Identified", fail_time, {class="hl-string">"IsStraightThroughProcessing": class="hl-string">"False"})
    elif status == class="hl-string">"APPROVED" and tx.get(class="hl-string">"retryCount", 0) > 0:
        class=class="hl-string">"hl-comment"># Logic: If approved but had retries, an error was resolved
        add_event(class="hl-string">"Payment Error Resolved", submission_time) class=class="hl-string">"hl-comment"># Simplified assumption

    class=class="hl-string">"hl-comment"># 5. Payment Approved
    approval_time = tx.get(class="hl-string">"approvalTime")
    if approval_time:
        add_event(class="hl-string">"Payment Approved", approval_time)

    class=class="hl-string">"hl-comment"># 6. Payment Authorized
    auth_time = tx.get(class="hl-string">"authorizationTime")
    class=class="hl-string">"hl-comment"># If separate auth time not provided, use approval time
    if not auth_time and approval_time:
        auth_time = approval_time
    add_event(class="hl-string">"Payment Authorized", auth_time)

    class=class="hl-string">"hl-comment"># 7. Payment Scheduled (if future dated)
    req_exec_date = tx.get(class="hl-string">"requestedExecutionDate")
    if req_exec_date and req_exec_date > submission_time:
         add_event(class="hl-string">"Payment Scheduled", submission_time)

    class=class="hl-string">"hl-comment"># 8. Payment Instruction Sent
    gateway_time = tx.get(class="hl-string">"gatewayTransmitTime")
    add_event(class="hl-string">"Payment Instruction Sent", gateway_time)

    class=class="hl-string">"hl-comment"># 9. Payment Confirmed (Gateway ACK)
    gateway_ack = tx.get(class="hl-string">"gatewayAckTime")
    add_event(class="hl-string">"Payment Confirmed", gateway_ack)

    class=class="hl-string">"hl-comment"># 10. Payment Settled
    settle_time = tx.get(class="hl-string">"settlementTime") or tx.get(class="hl-string">"fundingDate")
    add_event(class="hl-string">"Payment Settled", settle_time)

    class=class="hl-string">"hl-comment"># 11. Payment Notification Sent (Inferred or specific field)
    notify_time = tx.get(class="hl-string">"customerNotificationEmailTime")
    add_event(class="hl-string">"Payment Notification Sent", notify_time)

    class=class="hl-string">"hl-comment"># 12. Payment Reconciled
    recon_time = tx.get(class="hl-string">"reconciliationDate")
    add_event(class="hl-string">"Payment Reconciled", recon_time)

    class=class="hl-string">"hl-comment"># 13. Payment Cancelled
    if status == class="hl-string">"VOIDED" or status == class="hl-string">"CANCELLED":
        void_time = tx.get(class="hl-string">"voidTime") or tx.get(class="hl-string">"lastUpdateTime")
        add_event(class="hl-string">"Payment Cancelled", void_time)

    return events

class=class="hl-string">"hl-comment"># ==========================================
class=class="hl-string">"hl-comment"># MAIN EXTRACTION LOOP
class=class="hl-string">"hl-comment"># ==========================================
def main():
    all_events = []
    page_number = 1
    has_more = True
    
    print(fclass="hl-string">"Starting extraction from {START_DATE} to {END_DATE}...")

    while has_more:
        class=class="hl-string">"hl-comment"># Construct Search Payload
        payload_dict = {
            class="hl-string">"startDate": START_DATE,
            class="hl-string">"endDate": END_DATE,
            class="hl-string">"page": page_number,
            class="hl-string">"limit": PAGE_SIZE
        }
        payload_json = json.dumps(payload_dict)
        
        headers = generate_headers(payload_json)
        full_url = BASE_URL + ENDPOINT
        
        try:
            response = requests.post(full_url, headers=headers, data=payload_json)
            
            if response.status_code == 200:
                data = response.json()
                transactions = data.get(class="hl-string">"reports", []) class=class="hl-string">"hl-comment"># Key depends on specific endpoint schema
                
                if not transactions:
                    print(fclass="hl-string">"No transactions found on page {page_number}. Finishing.")
                    has_more = False
                    break
                
                print(fclass="hl-string">"Processing page {page_number}, found {len(transactions)} transactions.")
                
                for tx in transactions:
                    events = extract_events_from_transaction(tx)
                    all_events.extend(events)
                
                class=class="hl-string">"hl-comment"># Pagination Check
                total_pages = data.get(class="hl-string">"totalPages", page_number)
                if page_number >= total_pages:
                    has_more = False
                else:
                    page_number += 1
            else:
                print(fclass="hl-string">"Error fetching data: {response.status_code} - {response.text}")
                has_more = False
                
        except Exception as e:
            print(fclass="hl-string">"Exception occurred: {str(e)}")
            has_more = False

    class=class="hl-string">"hl-comment"># ==========================================
    class=class="hl-string">"hl-comment"># EXPORT TO CSV
    class=class="hl-string">"hl-comment"># ==========================================
    if all_events:
        df = pd.DataFrame(all_events)
        class=class="hl-string">"hl-comment"># Column ordering
        cols = [
            class="hl-string">"PaymentTransactionId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", 
            class="hl-string">"SourceSystem", class="hl-string">"PaymentAmount", class="hl-string">"CurrencyCode", class="hl-string">"PaymentMethod",
            class="hl-string">"PayerAccountNumber", class="hl-string">"ErrorCode", class="hl-string">"IsStraightThroughProcessing"
        ]
        class=class="hl-string">"hl-comment"># Ensure columns exist even if empty
        for c in cols:
            if c not in df.columns:
                df[c] = None
                
        df = df[cols]
        df.to_csv(OUTPUT_FILE, index=False)
        print(fclass="hl-string">"Extraction complete. {len(df)} rows written to {OUTPUT_FILE}")
    else:
        print(class="hl-string">"No events extracted.")

if __name__ == class="hl-string">"__main__":
    main()

Kezdje el most?

Kezdje el fejleszteni pénzügyi munkafolyamatait: alkalmazza ezt a sablont a Fiserv-környezetére. Útmutatónk segít kiválasztani azokat az adatokat, amelyekkel érdemi javulást érhet el a pénzáramlásban és a működési megfelelésben.

Vissza a folyamatfejlesztési útmutatóhoz

Sablon letöltése

Fejlessze a fizetésfeldolgozást, és érje el a 98%-os STP-arányt még ma

Szüntesse meg az egyeztetési késedelmeket, és lássa át Fiserv-munkafolyamatait.

Indítsa el az ingyenes próbaverziót

Nincs szükség bankkártyára. Beállítás néhány perc alatt.

Fizetésfeldolgozási adatsablon

Fizetésfeldolgozási adatsablon

A fizetésfeldolgozás attribútumai

A fizetésfeldolgozás tevékenységei

Adatkinyerési útmutatók

Python-szkript a Fiserv Commerce Hub API-hoz

Lépések

1. Előfeltételek beállítása

2. Környezet beállítása

3. A szkript beállítása

4. A hitelesítés beállítása

5. Az adatok feldolgozásának megértése

6. Lapozás kezelése

7. Futtatás

8. A kimenet ellenőrzése

9. Utófeldolgozás (nem kötelező)

10. Feltöltés a ProcessMindba

Konfiguráció

Példa-lekérdezés python

Kezdje el most?

Fejlessze a fizetésfeldolgozást, és érje el a 98%-os STP-arányt még ma