Uw betalingsverwerking datatemplate
Uw betalingsverwerking datatemplate
- Aanbevolen attributen om vast te leggen
- Belangrijkste activiteiten om te volgen
- Extractiehandleiding voor ACI Worldwide
Attributen Betalingsverwerkingingng
| Naam | Beschrijving | ||
|---|---|---|---|
| Activiteitsnaam ActivityName | De specifieke stap of statuswijziging die plaatsvond in de betalingslevenscyclus. | ||
| Beschrijving Dit attribuut definieert de gebeurtenis node in de proceskaart, zoals 'Betalingsaanvraag aangemaakt' of 'Fondsen Overgemaakt'. In ACI-systemen wordt dit vaak afgeleid van statuscodes, auditlog operation types of workflow state changes. Een accurate mapping van deze technische statussen naar leesbare bedrijfsactiviteiten is belangrijk voor een zinvolle visualisatie. Waarom het belangrijk is Het definieert de processtroom en is noodzakelijk om de volgorde van operaties te visualiseren. Waar te verkrijgen Afgeleid uit statuscodes (bijv. 100=Aangemaakt, 200=Gevalideerd) of Audit Log Action kolommen. Voorbeelden Betalingsaanvraag aangemaaktBetaling geautoriseerdBetaling afgewikkeldBetaling Mislukt | |||
| Payment Transaction ID PaymentTransactionId | De unieke ID voor de specifieke betaalopdracht binnen het ACI-systeem. | ||
| Beschrijving Dit attribuut dient als de centrale sleutel voor de process mining-analyse, en koppelt alle gebeurtenissen die verband houden met één enkele betalingsaanvraag. In ACI Worldwide systemen (zoals MTS of UPP) komt dit overeen met het unieke referentienummer dat bij invoer aan een transactie wordt toegewezen. Het maakt de reconstructie mogelijk van de end-to-end betalingsreis, vanaf de initiële aanvraag via validatie, goedkeuring en uiteindelijke afwikkeling. Waarom het belangrijk is Het is de fundamentele Case-ID die nodig is om discrete gebeurtenissen te groeperen in procesinstanties. Waar te verkrijgen Controleer transactieheader-tabellen, vaak gelabeld als TRN_REF, REFERENCE_NUM of UUID in het hoofdtransactielogboek. Voorbeelden TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| Tijdstempel EventTimestamp | De specifieke datum en tijd waarop de activiteit plaatsvond. | ||
| Beschrijving Dit attribuut registreert het exacte moment waarop een gebeurtenis plaatsvond binnen de ACI-omgeving. Het wordt gebruikt om alle tijdgerelateerde meetwaarden te berekenen, inclusief cyclustijden, goedkeuringsduren en doorvoerpercentages. Hoge precisie (milliseconden) heeft de voorkeur om snelle geautomatiseerde stappen nauwkeurig te sequencen. Waarom het belangrijk is Essentieel voor het ordenen van gebeurtenissen en het berekenen van prestatieduren. Waar te verkrijgen Raadpleeg de kolommen 'Created Date' of 'Update Date' in de transactiegeschiedenis- of audit tabellen. Voorbeelden 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| Afdeling Department | De interne afdeling die verantwoordelijk is voor de huidige activiteit. | ||
| Beschrijving Koppelt de Waarom het belangrijk is Aggregeert prestaties per bedrijfsfunctie. Waar te verkrijgen Afgeleid uit gebruikerstabellen of de Organizational Hierarchy mapping. Voorbeelden Operationele takenComplianceTreasuryIT Support | |||
| Betaalbedrag PaymentAmount | De financiële waarde van de betalingstransactie. | ||
| Beschrijving Geeft de financiële waarde aan die wordt overgemaakt. Dit is een belangrijk contextveld voor het analyseren van 'Betalingsdoorvoer' en het prioriteren van knelpunten. Hoogwaardige betalingen doorlopen vaak rigoureuzere goedkeuringspaden (variantanalyse) vergeleken met geautomatiseerde flows met lage waarde. Waarom het belangrijk is Maakt segmentatie naar waarde en berekening van het totale verwerkte volume mogelijk. Waar te verkrijgen Transactiedetailtabellen, typisch velden zoals AMT, TRANS_AMOUNT of PRINCIPAL_AMOUNT. Voorbeelden 1500.00250000.5050.001000000.00 | |||
| Betaaltype PaymentType | De classificatie van het betaalinstrument. | ||
| Beschrijving Categoriseert de betaling (bijv. Wire, ACH, SEPA, RTGS). Verschillende betalingstypen hebben vaak aanzienlijk verschillende SLA's en processtromen. Dit attribuut is een primaire dimensie voor het filteren van het 'End-to-End Betalingscyclustijd' dashboard. Waarom het belangrijk is Belangrijk voor het onderscheiden tussen snelle en gebatchede betalingsstromen. Waar te verkrijgen Transactieheader, velden zoals PMT_TYPE, INSTRUMENT_TYPE of SERVICE_ID. Voorbeelden Binnenlandse overboekingInternationale overboekingACH CreditDirecte Betaling | |||
| Betaalvaluta PaymentCurrency | De ISO-valutacode voor het betalingsbedrag. | ||
| Beschrijving Specificeert de valuta waarin het Waarom het belangrijk is Verplicht om het Betalingsbedrag correct te interpreteren. Waar te verkrijgen Transactiedetailtabellen, typisch velden zoals CCY, CURRENCY_CODE of ISO_CODE. Voorbeelden USDEURGBPJPY | |||
| Event Gebruiker EventUser | De gebruikers-id of systeemagent die verantwoordelijk is voor de activiteit. | ||
| Beschrijving Legt vast wie de actie heeft uitgevoerd – of het nu een menselijke gebruiker was (bijv. voor goedkeuringen) of een systeemaccount (bijv. voor geautomatiseerde afwikkeling). Dit attribuut is belangrijk voor 'Knelpuntenanalyse' om te vinden of specifieke gebruikers of wachtrijen overbelast zijn. Waarom het belangrijk is Maakt bronanalyse en audit van functiescheiding mogelijk. Waar te verkrijgen Audit logs of 'UpdatedBy' kolommen in transactietabellen. Voorbeelden SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS | |||
| Foutcode ErrorCode | De code die wordt gegenereerd wanneer een betaling mislukt of herstel vereist. | ||
| Beschrijving Legt de specifieke reden vast voor een 'Betaling mislukt' of 'Betalingsfout geïdentificeerd' gebeurtenis. Groepering op basis van dit attribuut in het 'Analyse van betalingsfouten en rework' dashboard stelt het bedrijf in staat om de meest voorkomende hoofdoorzaken van mislukking te vinden (bijv. 'Onvoldoende saldo', 'Ongeldige rekening'). Waarom het belangrijk is Essentieel voor oorzaakanalyse van procesfouten. Waar te verkrijgen Fout logs of status reden kolommen, vaak REASON_CODE of RETURN_CODE. Voorbeelden R01AM04BE05TECH_ERR_001 | |||
| Is herstelwerk IsRework | Vlag die aangeeft of de betaling repetitieve activiteiten heeft ondergaan. | ||
| Beschrijving Een booleaanse vlag die wordt berekend tijdens de gegevensverwerking. Deze wordt op 'true' ingesteld als activiteiten zoals 'Payment Details Validated' meer dan eens voorkomen of als er een foutlus wordt gedetecteerd. Dit stuurt de KPI 'Payment Rework Rate'. Waarom het belangrijk is Identificeert snel inefficiënte gevallen zonder complexe procesqueries. Waar te verkrijgen Berekend in de data pijplijn door te controleren op dubbele activiteiten per case. Voorbeelden truefalse | |||
| Uiterste betaaldatum PaymentDueDate | De datum waarop de betaling moet zijn afgewikkeld om als tijdig te worden beschouwd. | ||
| Beschrijving Slaat de contractuele of aangevraagde uitvoeringsdatum op. Deze datum wordt vergeleken met de werkelijke afwikkelingsdatum om de 'On-Time Payment Rate' KPI te berekenen en het 'Payment Due Date Compliance' dashboard te ondersteunen. Waarom het belangrijk is De benchmark voor het meten van SLA-compliance en on-time prestaties. Waar te verkrijgen Transactie-instructies, meestal VALUE_DATE, EXECUTION_DATE of DUE_DATE. Voorbeelden 2023-11-012023-11-05 | |||
| Verwerkingskanaal ProcessingChannel | Het kanaal waarlangs de betaling werd geïnitieerd. | ||
| Beschrijving Geeft het toegangspunt van de betaling aan, zoals Mobiel, Web Portal, API of Bestand uploaden. Dit helpt bij 'Analyse van betalingsprocesvarianten' om te zien of bepaalde kanalen gevoeliger zijn voor fouten of vertragingen dan andere. Waarom het belangrijk is Segmenteert prestaties op invoermethode. Waar te verkrijgen Transactieheader, vaak in kolommen genaamd CHANNEL, SOURCE_TYPE of INPUT_METHOD. Voorbeelden SWIFTInternetbankierenMobiele appBestand uploaden | |||
| Begunstigde naam BeneficiaryName | De naam van de entiteit die de betaling ontvangt. | ||
| Beschrijving Identificeert de tegenpartij in de transactie. Het analyseren van dit veld kan helpen bij het vinden van specifieke leveranciers of klanten die geassocieerd zijn met hoge reworkingspercentages of vertragingen, ter ondersteuning van de 'Analyse van betalingsfouten en rework'. Waarom het belangrijk is Identificeert de ontvanger van de betaling, nuttig voor klantgerichte analyse. Waar te verkrijgen Betalingsdetailregels, velden zoals CREDITOR_NAME, BENE_NAME of PAYEE. Voorbeelden Acme CorpWereldwijd Supplies LtdJohn Smith | |||
| Bronsysteem SourceSystem | De naam van het systeem waar de gebeurtenis data is ontstaan. | ||
| Beschrijving Identificeert de specifieke applicatie of module binnen het ACI Worldwide-ecosysteem (bijv. ACI MTS, ACI UPF) of externe systemen die betrokken zijn bij de stroom. Dit is met name belangrijk bij het samenvoegen van data over meerdere grootboeken of wanneer de betaling externe clearinghuizen raakt. Waarom het belangrijk is Biedt context over waar data is opgehaald, nuttig voor het debuggen van data lineage. Waar te verkrijgen Hardcoded tijdens extractie of afgeleid uit een SystemID kolom als er meerdere instanties bestaan. Voorbeelden ACI MTSACI UPPSAP GLSwift Gateway | |||
| Doorlooptijd goedkeuringscyclus ApprovalCycleTime | Duur doorgebracht in de goedkeuringsfase. | ||
| Beschrijving Berekent de tijd tussen 'Betaling ter goedkeuring verzonden' en 'Betaling goedgekeurd' (of afgewezen). Deze specifieke metriek voedt het 'Analyse van de goedkeuringscyclustijd van betalingen' dashboard, en benadrukt vertragingen in menselijke beslissingsstappen. Waarom het belangrijk is Isoleert het mensafhankelijke deel van het proces. Waar te verkrijgen Computed: Timestamp(Betaling goedgekeurd) - Timestamp(Betaling ter goedkeuring verzonden). Voorbeelden 4 uur15 minuten | |||
| Is Betaling Te Laat IsPaymentLate | Vlag die aangeeft of de betaling na de vervaldatum is afgewikkeld. | ||
| Beschrijving Een booleaanse vlag die de werkelijke afwikkelingsdatum vergelijkt met de Waarom het belangrijk is Vereenvoudigt compliancerapportage. Waar te verkrijgen Computed: SettlementDate > PaymentDueDate. Voorbeelden truefalse | |||
| Reconciliatie ID ReconciliationId | Identifier die de betaling koppelt aan het grootboek of de reconciliapakketecord. | ||
| Beschrijving Deze ID wordt ingevuld wanneer de activiteit 'Betaling Gereconcilieerd' plaatsvindt. Het zorgt ervoor dat de betaling in de verwerkingsengine overeenkomt met de invoer in het boekhoudsysteem. De afwezigheid van deze ID op afgewikkelde betalingen duidt op reconciliatiefouten. Waarom het belangrijk is Belangrijk voor het 'Efficiëntie van betalingsreconciliatie' dashboard. Waar te verkrijgen Reconciliatietabellen of specifieke velden zoals RECON_REF of GL_REF. Voorbeelden REC-9921GL-Entry-2023-11 | |||
| Regio van herkomst OriginatingRegion | De geografische regio waar de betalingsaanvraag is ontstaan. | ||
| Beschrijving Geeft de fysieke of logische locatie van de aanvrager aan. Dit is nuttig voor 'Analyse van betalingsprocesvarianten' om te zien of specifieke regio's niet-standaard paden volgen of hogere afwijzingspercentages ervaren. Waarom het belangrijk is Biedt geografische context voor procesprestaties. Waar te verkrijgen Transactieheader, vaak afgeleid van Branch Code of Land Code. Voorbeelden Noord-AmerikaEMEAAPAC | |||
| Tijdstip van extractie LastDataUpdate | De timestamp van wanneer de record voor het laatst is opgehaald of bijgewerkt in het data model. | ||
| Beschrijving Volgt de versheid van de data die in de analyse wordt gebruikt. Dit vertegenwoordigt geen proces-gebeurtenistijd, maar eerder de technische tijd van data-import. Het zorgt ervoor dat analysesten weten of ze naar real-time of historische snapshots kijken. Waarom het belangrijk is Zorgt voor datacurrency en helpt bij het vinden van verouderde data in dashboards. Waar te verkrijgen Systeemtijd op het moment van de uitvoering van het ETL-script. Voorbeelden 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
Activiteiten Betalingsverwerkingingng
| Activiteit | Beschrijving | ||
|---|---|---|---|
| Betaling afgewikkeld | De uiteindelijke bevestiging dat het betalingsproces is voltooid en de fondsen zijn bijgeschreven op de rekening van de begunstigde, waarmee de transactie wordt afgesloten. Dit is een kritieke gebeurtenis, die het succesvolle einde van de betalingslevenscyclus vertegenwoordigt. | ||
| Waarom het belangrijk is Dit is de primaire succesvolle eindgebeurtenis voor het proces. Het wordt gebruikt om de algehele cyclustijd en doorvoer te berekenen, en is belangrijk voor bijna alle end-to-end prestatiedashboards. Waar te verkrijgen Doorgaans een expliciete gebeurtenis die wordt vastgelegd wanneer een definitief afwikkelingsbevestigingsbericht van het netwerk wordt ontvangen of wanneer het interne grootboek wordt bijgewerkt om de voltooiing van de transactie weer te geven. Vastleggen Gelogd bij ontvangst van een definitief afwikkelingsbestand of -bericht, waarmee de status wordt bijgewerkt naar 'Afgehandeld'. Gebeurtenistype explicit | |||
| Betaling geautoriseerd | Vertegenwoordigt de autorisatie van de betaling op systeemniveau na menselijke goedkeuring, waarbij fondsen worden geverifieerd of gecontroleerd op fraude. Dit kan een expliciete logboekvermelding zijn of worden afgeleid uit een statuswijziging die aangeeft dat het klaar is voor uitvoering. | ||
| Waarom het belangrijk is Dit is een kritiek controlepunt voordat instructies voor fondsverplaatsing worden gegeven. Vertragingen in dit stadium kunnen duiden op problemen met systeemprestaties of met compliance- en fraudecontrolesubsystemen. Waar te verkrijgen Controleer op een expliciete log in een systeemverwerkings- of beveiligingslogboek. Alternatief kan het worden afgeleid uit een statusupdate van 'Goedgekeurd' naar 'Geautoriseerd voor betaling'. Vastleggen Gelogd door de betalingsengine van het systeem na het doorstaan van de laatste interne controles. Gebeurtenistype explicit | |||
| Betaling goedgekeurd | Een belangrijke mijlpaal waarbij een geautoriseerde gebruiker de betaling goedkeurt, waardoor deze kan doorgaan naar uitvoering. Dit wordt meestal vastgelegd als een expliciete gebeurtenis wanneer de goedkeurder actie onderneemt in de gebruikersinterface van het systeem. | ||
| Waarom het belangrijk is Deze activiteit is een belangrijk controlepunt en vaak een aanzienlijke bottleneck. Het analyseren van wachttijden voor deze stap en de duur van de goedkeuringscyclus helpt bij het vinden van kansen om betalingen te versnellen. Waar te verkrijgen Zoek naar een expliciete gebeurtenis in een goedkeuringslogtabel of een statuswijziging naar 'Goedgekeurd' in de hoofdtransactietabel die gekoppeld is aan een specifieke gebruikersactie en timestamp. Vastleggen Gelogd wanneer een geautoriseerde gebruiker de goedkeuringsactie in het systeem voltooit. Gebeurtenistype explicit | |||
| Betalingsaanvraag aangemaakt | Deze activiteit markeert de initiatie van een nieuwe betalingstransactie binnen het ACI Worldwide systeem. Het is doorgaans een expliciete gebeurtenis die wordt vastgelegd wanneer een gebruiker of een upstream systeem een betalingsaanvraag indient, waardoor een nieuw transacpakketecord met een unieke ID wordt gecreëerd. | ||
| Waarom het belangrijk is Dit is de primaire startgebeurtenis voor het betalingsproces. Het analyseren van de tijd van deze activiteit tot voltooiing levert de end-to-end cyclustijd op, die belangrijk is voor het meten van de algehele procesefficiëntie. Waar te verkrijgen Dit is waarschijnlijk een expliciete gebeurtenis die is vastgelegd in de kerntransactietabel of een speciaal event log in ACI. Zoek naar een creation timestamp geassocieerd met de Payment Transaction ID. Vastleggen Geïdentificeerd door de aanmaakrecord of een expliciete 'Aanmaak' gebeurtenis in het transactielogboek. Gebeurtenistype explicit | |||
| Betalingsfout geïdentificeerd | Geeft aan dat het systeem in een bepaald stadium een probleem met de betaling heeft gedetecteerd, zoals ongeldige data of een compliance-alert. Deze gebeurtenis wordt doorgaans expliciet gelogd met een bijbehorende foutcode. | ||
| Waarom het belangrijk is Deze activiteit is het startpunt voor alle herstelwerks- en uitzonderingsafhandelinganalyses. Het is belangrijk voor de 'Betalingsfout- en Herbewerkingsanalyse' en 'Foutoplossingstijd' dashboards. Waar te verkrijgen Zoek naar expliciete entries in een foutlogtabel of een statuswijziging naar 'Fout' of 'Verplicht correctie' in de transactietabel. Deze gebeurtenissen moeten gekoppeld zijn aan de Payment Transaction ID. Vastleggen Een expliciete gebeurtenis wordt gelogd wanneer de validatie- of verwerkingsengine van het systeem een fout signaleert. Gebeurtenistype explicit | |||
| Gelden overgemaakt | Geeft aan dat bevestiging is ontvangen van het betalingsnetwerk dat gelden succesvol zijn afgeschreven van de rekening van de betaler. Dit wordt meestal vastgelegd uit een inkomend statusbericht van het netwerk. | ||
| Waarom het belangrijk is Bevestigt de succesvolle uitvoering van de betaling door het externe netwerk. Het markeert het begin van de afwikkelingsperiode en is een belangrijke input voor de KPI 'Gemiddelde afwikkelingstijd van betalingen'. Waar te verkrijgen Dit is een expliciete gebeurtenis die wordt geactiveerd door een inkomend statusupdatebericht (bijv. MT103 van SWIFT, of een ACH-bevestiging) dat het betalingsrecord bijwerkt. Vastleggen Gelogd bij ontvangst van een extern bevestigingsbericht van het clearingnetwerk. Gebeurtenistype explicit | |||
| `Betaling` bevestigd | Vertegenwoordigt de interne bevestiging dat de betaling succesvol is verwerkt en een bevestiging is ontvangen. Dit fungeert vaak als het triggerpunt voor het Informapakketmeren van de begunstigde of andere interne systemen. | ||
| Waarom het belangrijk is Deze mijlpaal is belangrijk voor het meten van due date compliance en On-Time Payment Rate. Het biedt een duidelijke timestamp voor wanneer de organisatie de betaling als succesvol uitgevoerd beschouwt. Waar te verkrijgen Dit wordt doorgaans afgeleid uit een statuswijziging in de betalingstransactietabel naar een 'Bevestigde' of 'Voltooide' status nadat externe netwerkbevestiging is ontvangen. Vastleggen Afgeleid uit een statuswijziging naar 'Bevestigd' of 'Verwerkt'. Gebeurtenistype inferred | |||
| Betaalopdracht Verzonden | Markeert het punt waar de betalingsinstructie wordt gecompileerd en verzonden naar een extern betalingsnetwerk zoals SWIFT, ACH of SEPA. ACI-systemen loggen deze overdracht expliciet voor audit- en trackingdoeleinden. | ||
| Waarom het belangrijk is Dit is het 'point of no return' voor veel betalingstypes. Het volgen hiervan helpt bij het meten van de interne verwerkingstijd voordat externe afhankelijkheden het overnemen. Waar te verkrijgen Dit is bijna altijd een expliciete gebeurtenis die is vastgelegd in de transactie- of berichtlogboeken van ACI, vaak inclusief een netwerkspecifiek referentienummer. Vastleggen Een expliciete log entry wordt aangemaakt wanneer de betalingsboodschap naar het externe netwerk wordt verzonden. Gebeurtenistype explicit | |||
| Betaling afgestemd | Vertegenwoordigt de laatste boekhoudkundige stap waarbij de in ACI vastgelegde betalingstransactie wordt vergeleken met bankafschriften of grootboekboekingen. Dit kan een expliciete gebeurtenis zijn vanuit een reconciliatiemodule of worden afgeleid uit een statuswijziging. | ||
| Waarom het belangrijk is Deze activiteit meet de efficiëntie van het backoffice-reconciliatieproces. Vertragingen hier kunnen de nauwkeurigheid van financiële rapportage beïnvloeden en onafgewikkelde betalingsproblemen verbergen. Waar te verkrijgen Deze Informatie kan afkomstig zijn van een speciale reconciliatiemodule binnen ACI of een extern ERP-systeem. Het zou worden vastgelegd via een statusupdate naar 'Gereconcilieerd' op het betalingsrecord. Vastleggen Afgeleid uit een finale 'Gereconcilieerd' statusupdate, of uit reconciliatiedata samengevoegd per Betalings-ID. Gebeurtenistype inferred | |||
| Betaling Afgewezen | Treedt op wanneer een goedkeurder het betaalverzoek weigert, wat vaak correctie en opnieuw indienen vereist. Dit is een expliciete gebeurtenis die de voortgang van de betaling stopt en een reworkingslus initieert. | ||
| Waarom het belangrijk is Identificeert rework en procesinefficiënties. Het volgen van de frequentie van afwijzingen helpt bij het diagnosticeren van problemen met de initiële datakwaliteit of indieningsbeleid, ter ondersteuning van reworkanalyse. Waar te verkrijgen Vastgelegd als een expliciete gebeurtenis in het goedkeuringslogboek of een statuswijziging naar 'Afgewezen' in de transactietabel. De gebeurtenis kan een redencode voor de afwijzing bevatten. Vastleggen Gelogd wanneer een goedkeurder de afwijzingsactie in het systeem voltooit. Gebeurtenistype explicit | |||
| Betaling Mislukt | Een terminale status die aangeeft dat de betaling niet kon worden voltooid vanwege een onherstelbaar probleem. Dit verschilt van een oplosbare fout en vertegenwoordigt een definitieve eindstatus van mislukking. | ||
| Waarom het belangrijk is Het volgen van deze eindgebeurtenis is belangrijk voor het berekenen van het algehele betalingsfaalpercentage. Het analyseren van de redenen voor falen kan helpen de datakwaliteit en procesregels te verbeteren. Waar te verkrijgen Afgeleid uit een finale, terminale status zoals 'Mislukt', 'Geannuleerd' of 'Afgewezen door Bank' in de transactiedata, die nadien niet meer verandert. Vastleggen Afgeleid uit een terminale mislukt-status in de betalingsrecord. Gebeurtenistype inferred | |||
| Betaling Ter Goedkeuring Verzonden | Geeft aan dat de betaling de initiële validatie heeft doorstaan en is doorgestuurd voor de nodige management- of financiële goedkeuring. Dit wordt doorgaans vastgelegd door een statuswijziging binnen de betalingsworkflow. | ||
| Waarom het belangrijk is Dit markeert het begin van het goedkeurings-subproces. Het meten van de tijd vanaf dit punt tot 'Betaling Goedgekeurd' is belangrijk voor het 'Payment Approval Cycle Time Analysis' dashboard. Waar te verkrijgen Afgeleid uit een wijziging in het betalingsstatusveld in de transactiedata, zoals het overgaan naar 'In afwachting van goedkeuring'. Vastleggen Afgeleid uit een statuswijziging naar 'In afwachting van goedkeuring' of vergelijkbaar, samen met een corresponderende timestamp. Gebeurtenistype inferred | |||
| Betalingsdetails Gervalideerd | Vertegenwoordigt de voltooiing van geautomatiseerde of handmatige controles om te garanderen dat betalingsdetails, zoals begunstigde-Informatie en bankcodes, correct zijn. Deze activiteit wordt vaak afgeleid uit een statuswijziging van de transactie van 'Nieuw' naar 'Gevalideerd' of 'Wachtend op Goedkeuring'. | ||
| Waarom het belangrijk is Volgt de efficiëntie van de initiële datavalidatiestappen. Vertragingen hier kunnen upstream knelpunten creëren en de waarschijnlijkheid van betalingsfouten later in het proces vergroten. Waar te verkrijgen Afgeleid uit statuswijzigingsvelden in de hoofdtransactietabel van betalingen. Vergelijk tijdstempels tussen de status 'Aangemaakt' en een daaropvolgende 'Gevalideerd' of vergelijkbare status. Vastleggen Afgeleid uit een wijziging in het betalingsstatusveld, bijvoorbeeld van 'Ingevoerd' naar 'Gevalideerd'. Gebeurtenistype inferred | |||
| Betalingsfout Opgelost | Markeert het punt waar een eerder geïdentificeerde fout door een gebruiker is gecorrigeerd en de betaling opnieuw ter verwerking wordt aangeboden. Dit wordt vaak afgeleid wanneer de status van een betaling verandert van een foutstatus terug naar een normale verwerkingsstatus. | ||
| Waarom het belangrijk is Deze activiteit sluit de uitzonderingsloop. De tijd tussen 'Betalingsfout geïdentificeerd' en deze gebeurtenis is de foutoplossingstijd, een belangrijke maatstaf voor operationele efficiëntie. Waar te verkrijgen Afgeleid uit een statuswijziging van een 'Fout'-status naar een verwerkingsstatus zoals 'In afwachting van goedkeuring' of 'Gevalideerd'. Het kan ook een expliciete gebruikersactielog zijn. Vastleggen Afgeleid uit een statuswijziging vanuit een foutstatus, wat aangeeft dat een correctie is uitgevoerd. Gebeurtenistype inferred | |||
Extractiegidsen
Stappen
Toegang tot de database-omgeving: Log in op de SQL Server-instantie van de ACI Postilion Realtime-database via SQL Server Management Studio (SSMS) of een vergelijkbare client.
Identificeer kerntabellen: Zoek de tabellen
post_tran(transactielogboek) enpost_tran_cust(extensie voor aangepaste data). Zorg dat uSELECT-rechten heeft voor deze objecten.Bepaal de Case Identifier: Deze extractie gebruikt de
retrieval_reference_nralsPaymentTransactionId. Indien uw omgeving een andere unieke sleutel gebruikt (zoalssystem_trace_audit_nrgecombineerd mettransmission_date_time), pas dan de query aan.Filterparameters configureren: Open de onderstaande query. Zoek bovenaan het script de variabelen
@StartDateen@EndDate. Stel deze in op de gewenste periode (bijv. de laatste 30 tot 90 dagen) voor optimale prestaties.Controleer de activiteitenlogica: De query koppelt ISO 8583-berichttypen (zoals 0200, 0210) en responscodes aan de 14 standaardactiviteiten. Controleer de
CASE-statements zodat deze aansluiten op uw specifieke ACI-configuratie.Voer de query uit: Start het volledige script. De query gebruikt
UNION ALLom verschillende transactiestatussen te normaliseren naar één event log-formaat.Controleer de data-output: Controleer de kolommen
PaymentTransactionId,ActiviteitNaamenEventTimestamp. Let erop dat essentiële velden geen onverwachteNULL-waarden bevatten.Data exporteren: Klik met de rechtermuisknop op de resultaten in SSMS en sla deze op als CSV-bestand (bijv.
ACI_Payments_EventLog.csv).Formatteren voor ProcessMind: Open de CSV en controleer of
EventTimestamphet standaardformaat (YYYY-MM-DD HH:MM:SS) heeft en ofPaymentBedragalleen numerieke waarden bevat.Uploaden: Importeer de gecontroleerde CSV in ProcessMind en koppel de kolommen aan Case-ID, Activiteit en Timestamp.
Configuratie
- Datumbereik: ACI
post_tran-tabellen groeien zeer snel. Het is raadzaam de extractie te beperken tot een rollende periode van 3 maanden of partition switching te gebruiken. - Responscodes: De query gaat ervan uit dat
rsp_code = '00'staat voor succes. Gebruikt uw organisatie andere codes voor goedkeuring (zoals '08' of '10'), pas dan de filters aan. - Berichttypen (ISO 8583): Het script vertrouwt op standaard berichttypen (0100/0200 voor Requests, 0210 voor Responses). Bij afwijkende berichttypen in uw
source_node_name-configuratie zijn aanpassingen nodig. - Systeemprestaties: Deze query gebruikt
NOLOCK-hints om te voorkomen dat lopende transacties worden geblokkeerd. Verwijder deze hints niet in een productieomgeving. - Valuta: Bedragen worden als ruwe cijfers geëxporteerd. Gebruik
tran_currency_codeals normalisatie van verschillende valuta nodig is voor de analyse.
a Voorbeeldquery 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;