Ihr Daten-Template für die Zahlungsabwicklung
Ihr Daten-Template für die Zahlungsabwicklung
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten für die Erfassung
- Hinweise zum Datenexport aus ACI Worldwide
Attribute der Zahlungsabwicklung
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der konkrete Schritt oder die Statusänderung im Lebenszyklus der Zahlung. | ||
| Beschreibung Dieses Attribut legt den Ereignisknoten in der Prozessübersicht fest, zum Beispiel „Zahlungsanfrage erstellt“ oder „Betrag überwiesen“. In ACI-Systemen wird es häufig aus Statuscodes, Vorgangstypen im Audit-Protokoll oder Änderungen des Workflow-Status abgeleitet. Damit die Visualisierung aussagekräftig ist, müssen diese technischen Zustände korrekt verständlichen Geschäftsaktivitäten zugeordnet werden. Warum das wichtig ist Das Attribut definiert den Prozessablauf und ist erforderlich, um die Reihenfolge der Vorgänge darzustellen. Woher beziehen Abgeleitet aus Statuscodes (z. B. 100=Erstellt, 200=Validiert) oder aus Aktionsspalten im Audit-Protokoll. Beispiele Zahlungsanforderung erstelltZahlung autorisiertZahlung abgewickeltZahlung fehlgeschlagen | |||
| Ereignis-Timestamp EventTimestamp | Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat. | ||
| Beschreibung Dieses Attribut erfasst den genauen Zeitpunkt eines Ereignisses in der ACI-Umgebung. Es dient zur Berechnung aller zeitbezogenen Kennzahlen, darunter Zykluszeiten, Genehmigungsdauer und Durchsatzraten. Für eine präzise Reihenfolge schnell aufeinanderfolgender automatisierter Schritte empfiehlt sich eine hohe Genauigkeit im Millisekundenbereich. Warum das wichtig ist Unverzichtbar, um Ereignisse zu ordnen und Leistungszeiträume zu berechnen. Woher beziehen Prüfen Sie die Spalten „Erstellungsdatum“ oder „Änderungsdatum“ im Transaktionsverlauf oder in den Audit-Tabellen. Beispiele 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| Payment Transaction ID PaymentTransactionId | Der eindeutige Bezeichner für den jeweiligen Zahlungsauftrag im gesamten ACI-System. | ||
| Beschreibung Dieses Attribut dient als zentraler Schlüssel für die Process-Mining-Analyse und verknüpft alle Ereignisse zu einer einzelnen Zahlungsanfrage. In ACI Worldwide-Systemen wie MTS oder UPP entspricht es der eindeutigen Referenznummer, die einer Transaktion bei der Erfassung zugewiesen wird. Damit lässt sich der gesamte Zahlungsablauf rekonstruieren, von der ursprünglichen Anfrage über Validierung und Genehmigung bis zur abschließenden Abrechnung. Warum das wichtig ist Dies ist die grundlegende Case-ID, mit der einzelne Ereignisse zu Prozessinstanzen gruppiert werden. Woher beziehen Prüfen Sie die Transaktionskopftabellen. Die Felder heißen im Haupttransaktionsprotokoll häufig TRN_REF, REFERENCE_NUM oder UUID. Beispiele TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| Abteilung Department | Die interne Abteilung, die für die aktuelle Aktivität verantwortlich ist. | ||
| Beschreibung Ordnet den Warum das wichtig ist Fasst die Leistung nach Geschäftsbereich zusammen. Woher beziehen Abgeleitet aus Benutzertabellen oder einer Zuordnung zur Organisationshierarchie. Beispiele BetriebComplianceTreasuryIT-Support | |||
| Ereignisbenutzer EventUser | Die Benutzer-ID oder der Systemagent, der für die Aktivität verantwortlich ist. | ||
| Beschreibung Erfasst, wer die Aktion ausgeführt hat, ob ein Benutzer, etwa bei einer Genehmigung, oder ein Systemkonto, etwa bei einer automatisierten Abrechnung. Dieses Attribut ist für die Engpassanalyse wichtig, um überlastete Benutzer oder Warteschlangen zu erkennen. Warum das wichtig ist Ermöglicht die Ressourcenanalyse und die Prüfung der Funktionstrennung. Woher beziehen Audit-Protokolle oder Spalten wie „UpdatedBy“ in Transaktionstabellen. Beispiele SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS | |||
| Fälligkeitstermin der Zahlung PaymentDueDate | Das Datum, bis zu dem die Zahlung abgerechnet sein muss, damit sie als fristgerecht gilt. | ||
| Beschreibung Speichert das vertraglich vereinbarte oder angeforderte Ausführungsdatum. Durch den Vergleich mit dem tatsächlichen Abrechnungsdatum lässt sich die KPI „Anteil fristgerechter Zahlungen“ berechnen und das Dashboard „Einhaltung des Fälligkeitstermins“ unterstützen. Warum das wichtig ist Der Maßstab für die Messung der SLA-Einhaltung und der fristgerechten Ausführung. Woher beziehen Zahlungsaufträge, üblicherweise mit VALUE_DATE, EXECUTION_DATE oder DUE_DATE. Beispiele 2023-11-012023-11-05 | |||
| Fehlercode ErrorCode | Der Code, der bei einer fehlgeschlagenen oder zu korrigierenden Zahlung erzeugt wird. | ||
| Beschreibung Erfasst den konkreten Grund für ein Ereignis wie „Zahlung fehlgeschlagen“ oder „Zahlungsfehler erkannt“. Durch die Gruppierung nach diesem Attribut im Dashboard „Analyse von Zahlungsfehlern und Nacharbeit“ lassen sich die häufigsten Fehlerursachen ermitteln, etwa „Unzureichende Deckung“ oder „Ungültiges Konto“. Warum das wichtig ist Unverzichtbar für die Ursachenanalyse bei Prozessfehlern. Woher beziehen Fehlerprotokolle oder Spalten mit Statusgründen, häufig REASON_CODE oder RETURN_CODE. Beispiele R01AM04BE05TECH_ERR_001 | |||
| Nacharbeit erfolgt IsRework | Kennzeichen dafür, ob bei der Zahlung Aktivitäten wiederholt wurden. | ||
| Beschreibung Ein boolesches Kennzeichen, das bei der Datenverarbeitung berechnet wird. Es wird auf „true“ gesetzt, wenn Aktivitäten wie „Zahlungsdetails validiert“ mehr als einmal auftreten oder eine Fehlerschleife erkannt wird. Dieser Wert fließt in die KPI „Nacharbeitsquote bei Zahlungen“ ein. Warum das wichtig ist Erkennt ineffiziente Fälle schnell, ohne komplexe Prozessabfragen. Woher beziehen Wird in der Datenpipeline berechnet, indem doppelte Aktivitäten pro Case ermittelt werden. Beispiele truefalse | |||
| Verarbeitungskanal ProcessingChannel | Der Kanal, über den die Zahlung eingeleitet wurde. | ||
| Beschreibung Gibt den Eingangskanal der Zahlung an, zum Beispiel Mobile App, Webportal, API oder Datei-Upload. Mit der Variantenanalyse des Zahlungsprozesses lässt sich feststellen, ob bestimmte Kanäle häufiger zu Fehlern oder Verzögerungen führen. Warum das wichtig ist Vergleicht die Leistung nach Eingabemethode. Woher beziehen Transaktionskopf, häufig mit Spalten wie CHANNEL, SOURCE_TYPE oder INPUT_METHOD. Beispiele SWIFTOnlinebankingMobile AppDatei-Upload | |||
| Zahlungsart PaymentType | Die Klassifizierung des Zahlungsinstruments. | ||
| Beschreibung Kategorisiert die Zahlung, zum Beispiel als Wire, ACH, SEPA oder RTGS. Die Service-Level-Agreements und Prozessabläufe unterscheiden sich je nach Zahlungsart oft erheblich. Dieses Attribut ist eine zentrale Dimension für Filter im Dashboard „End-to-End-Zykluszeit von Zahlungen“. Warum das wichtig ist Wichtig, um schnelle Zahlungsabläufe von Sammelverarbeitungen zu unterscheiden. Woher beziehen Transaktionskopf, mit Feldern wie PMT_TYPE, INSTRUMENT_TYPE oder SERVICE_ID. Beispiele InlandsüberweisungInternationale ÜberweisungACH-GutschriftEchtzeitzahlung | |||
| Zahlungsbetrag PaymentAmount | Der Geldwert der Zahlungstransaktion. | ||
| Beschreibung Gibt den überwiesenen Geldbetrag an. Dieses Kontextattribut ist wichtig, um den „Zahlungsdurchsatz“ zu analysieren und Engpässe zu priorisieren. Bei Zahlungen mit hohem Wert sind häufig strengere Genehmigungsabläufe erforderlich als bei automatisierten Abläufen für kleinere Beträge. Das lässt sich durch eine Variantenanalyse untersuchen. Warum das wichtig ist Ermöglicht die Segmentierung nach Betrag und die Berechnung des insgesamt verarbeiteten Volumens. Woher beziehen Transaktionsdetailtabellen, üblicherweise mit Feldern wie AMT, TRANS_AMOUNT oder PRINCIPAL_AMOUNT. Beispiele 1500.00250000.5050.001000000.00 | |||
| Zahlungswährung PaymentCurrency | Der ISO-Währungscode des Zahlungsbetrags. | ||
| Beschreibung Gibt an, in welcher Währung der Warum das wichtig ist Erforderlich, um den Zahlungsbetrag korrekt zu interpretieren. Woher beziehen Transaktionsdetailtabellen, üblicherweise mit Feldern wie CCY, CURRENCY_CODE oder ISO_CODE. Beispiele USDEURGBPJPY | |||
| Abgleich-ID ReconciliationId | Bezeichner, der die Zahlung mit dem Hauptbuch oder dem Abstimmungsdatensatz verknüpft. | ||
| Beschreibung Diese ID wird eingetragen, wenn die Aktivität „Zahlung abgeglichen“ stattfindet. Sie stellt sicher, dass die Zahlung in der Verarbeitungs-Engine mit dem Eintrag im Buchhaltungssystem übereinstimmt. Fehlt die ID bei abgerechneten Zahlungen, deutet das auf Fehler beim Abgleich hin. Warum das wichtig ist Wichtig für das Dashboard „Effizienz des Zahlungsabgleichs“. Woher beziehen Abgleichstabellen oder bestimmte Felder wie RECON_REF oder GL_REF. Beispiele REC-9921GL-Entry-2023-11 | |||
| Genehmigungszykluszeit ApprovalCycleTime | Dauer der Genehmigungsphase. | ||
| Beschreibung Berechnet die Zeit zwischen „Zahlung zur Genehmigung gesendet“ und „Zahlung genehmigt“ (oder abgelehnt). Diese Kennzahl fließt in das Dashboard „Analyse der Genehmigungszykluszeit von Zahlungen“ ein und macht Verzögerungen bei menschlichen Entscheidungen sichtbar. Warum das wichtig ist Grenzt den Teil des Prozesses ab, der von menschlichen Entscheidungen abhängt. Woher beziehen Berechnet als: Timestamp(Zahlung genehmigt) - Timestamp(Zahlung zur Genehmigung gesendet). Beispiele 4 Stunden15 Minuten | |||
| Herkunftsregion OriginatingRegion | Die geografische Region, aus der die Zahlungsanfrage stammt. | ||
| Beschreibung Gibt den physischen oder logischen Standort des Anfragenden an. Mit der Variantenanalyse des Zahlungsprozesses lässt sich feststellen, ob bestimmte Regionen von den Standardabläufen abweichen oder häufiger Ablehnungen verzeichnen. Warum das wichtig ist Liefert den geografischen Kontext für die Prozessleistung. Woher beziehen Transaktionskopf, häufig abgeleitet aus Branch Code oder Country Code. Beispiele NordamerikaEMEAAPAC | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp der letzten Extraktion oder Aktualisierung des Datensatzes im Datenmodell. | ||
| Beschreibung Zeigt, wie aktuell die für die Analyse verwendeten Daten sind. Dieser Wert bezeichnet nicht den Zeitpunkt eines Prozessereignisses, sondern den technischen Zeitpunkt der Datenübernahme. So erkennen Analysten, ob sie Echtzeitdaten oder historische Datenstände betrachten. Warum das wichtig ist Zeigt, ob die Daten aktuell sind, und hilft dabei, veraltete Daten in Dashboards zu erkennen. Woher beziehen Systemzeit zum Zeitpunkt der Ausführung des ETL-Skripts. Beispiele 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
| Name des Zahlungsempfängers BeneficiaryName | Der Name der Einheit, die die Zahlung erhält. | ||
| Beschreibung Identifiziert den Geschäftspartner der Transaktion. Die Analyse dieses Feldes kann bestimmte Lieferanten oder Kunden aufzeigen, bei denen häufig Nacharbeit oder Verzögerungen auftreten. Das unterstützt die „Analyse von Zahlungsfehlern und Nacharbeit“. Warum das wichtig ist Gibt den Zahlungsempfänger an und eignet sich für kundenbezogene Analysen. Woher beziehen Zahlungsdetailzeilen, mit Feldern wie CREDITOR_NAME, BENE_NAME oder PAYEE. Beispiele Acme CorpGlobal Supplies LtdJohn Smith | |||
| Quellsystem SourceSystem | Der Name des Systems, aus dem die Ereignisdaten stammen. | ||
| Beschreibung Gibt die konkrete Anwendung oder das Modul im ACI Worldwide-Ökosystem an, etwa ACI MTS oder ACI UPF, oder ein externes System, das am Ablauf beteiligt ist. Das ist besonders wichtig, wenn Daten aus mehreren Hauptbüchern zusammengeführt werden oder die Zahlung über externe Clearingstellen läuft. Warum das wichtig ist Zeigt, aus welchem System die Daten extrahiert wurden, und erleichtert so die Fehlersuche in der Datenherkunft. Woher beziehen Bei der Extraktion fest vorgegeben oder aus einer SystemID-Spalte abgeleitet, wenn mehrere Instanzen vorhanden sind. Beispiele ACI MTSACI UPPSAP GLSwift Gateway | |||
| Zahlung verspätet IsPaymentLate | Kennzeichen dafür, ob die Zahlung nach dem Fälligkeitstermin abgerechnet wurde. | ||
| Beschreibung Ein boolesches Kennzeichen, das das tatsächliche Abrechnungsdatum mit Warum das wichtig ist Vereinfacht die Compliance-Berichterstattung. Woher beziehen Berechnet als: SettlementDate > PaymentDueDate. Beispiele truefalse | |||
Aktivitäten der Zahlungsabwicklung
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Gelder überwiesen | Zeigt an, dass das Zahlungsnetzwerk bestätigt hat, dass die Gelder erfolgreich vom Konto des Zahlers abgebucht wurden. Dies wird üblicherweise anhand einer eingehenden Statusnachricht des Netzwerks erfasst. | ||
| Warum das wichtig ist Bestätigt die erfolgreiche Ausführung der Zahlung durch das externe Netzwerk. Damit beginnt die Abwicklungsdauer. Das Ereignis ist eine wichtige Grundlage für den KPI „Average Payment Settlement Time“. Woher beziehen Dieses explizite Ereignis wird durch eine eingehende Statusnachricht ausgelöst, beispielsweise eine MT103-Nachricht von SWIFT oder eine ACH-Bestätigung, die den Zahlungseintrag aktualisiert. Erfassung Wird beim Eingang einer externen Bestätigungsnachricht des Clearing-Netzwerks erfasst. Ereignistyp explicit | |||
| Zahlung abgewickelt | Die abschließende Bestätigung, dass der Zahlungsvorgang beendet und das Geld dem Zahlungsempfänger gutgeschrieben wurde. Damit ist die Transaktion abgeschlossen. Dieses wichtige Ereignis kennzeichnet den erfolgreichen Abschluss des Zahlungslebenszyklus. | ||
| Warum das wichtig ist Dies ist das primäre End-Event für einen erfolgreichen Prozessabschluss. Es dient zur Berechnung der gesamten Zykluszeit und des Durchsatzes und ist für fast alle Dashboards zur durchgängigen Prozessleistung wichtig. Woher beziehen Wird üblicherweise als explizites Ereignis erfasst, wenn eine abschließende Abwicklungsbestätigung des Netzwerks eingeht oder das interne Hauptbuch aktualisiert wird, um den Abschluss der Transaktion festzuhalten. Erfassung Wird erfasst, sobald eine abschließende Abrechnungsdatei oder -nachricht eingeht, und setzt den Status auf „Abgerechnet“. Ereignistyp explicit | |||
| Zahlung autorisiert | Bezeichnet die Autorisierung der Zahlung auf Systemebene nach der Freigabe durch einen Menschen. Dabei werden die verfügbaren Mittel geprüft oder Betrugsregeln angewendet. Dies kann als expliziter Protokolleintrag erfasst oder aus einer Statusänderung abgeleitet werden, die die Ausführungsbereitschaft anzeigt. | ||
| Warum das wichtig ist Dies ist ein wichtiger Kontrollpunkt, bevor die Überweisung der Gelder veranlasst wird. Verzögerungen in dieser Phase können auf Leistungsprobleme des Systems oder Schwierigkeiten mit Compliance- und Betrugsprüfungen hinweisen. Woher beziehen Suchen Sie nach einem expliziten Eintrag in einem Systemverarbeitungs- oder Sicherheitsprotokoll. Alternativ lässt sich der Vorgang aus einer Statusänderung von „Approved“ zu „Authorized for Payment“ ableiten. Erfassung Wird von der Zahlungs-Engine des Systems erfasst, nachdem die abschließenden internen Prüfungen bestanden wurden. Ereignistyp explicit | |||
| Zahlung freigegeben | Ein wichtiger Meilenstein: Ein autorisierter Benutzer gibt die Zahlung frei, sodass sie ausgeführt werden kann. Üblicherweise wird dies als explizites Ereignis erfasst, wenn die freigebende Person die entsprechende Aktion in der Benutzeroberfläche des Systems ausführt. | ||
| Warum das wichtig ist Diese Aktivität ist ein wichtiger Kontrollpunkt und häufig ein erheblicher Engpass. Die Analyse der Wartezeiten vor diesem Schritt und der Dauer des Freigabezyklus zeigt, wo sich Zahlungen beschleunigen lassen. Woher beziehen Suchen Sie nach einem expliziten Ereignis in einer Freigabeprotokolltabelle oder nach einer Statusänderung zu „Approved“ in der zentralen Transaktionstabelle, die einer bestimmten Benutzeraktion und einem Timestamp zugeordnet ist. Erfassung Wird erfasst, wenn ein autorisierter Benutzer die Freigabe im System abschließt. Ereignistyp explicit | |||
| Zahlungsanforderung erstellt | Diese Aktivität kennzeichnet den Beginn einer neuen Zahlungstransaktion im System von ACI Worldwide. Üblicherweise wird sie als explizites Ereignis erfasst, wenn ein Benutzer oder ein vorgelagertes System eine Zahlungsanforderung übermittelt und dadurch einen neuen Transaktionsdatensatz mit einer eindeutigen ID anlegt. | ||
| Warum das wichtig ist Dies ist das primäre Start-Event des Zahlungsprozesses. Die Zeitspanne von dieser Aktivität bis zum Abschluss ergibt die durchgängige Zykluszeit und ist entscheidend für die Messung der Gesamteffizienz des Prozesses. Woher beziehen Dieses Ereignis ist wahrscheinlich explizit in der zentralen Transaktionstabelle oder in einem eigenen Event Log von ACI erfasst. Suchen Sie nach einem Erstellungs-Timestamp zur Payment Transaction ID. Erfassung Erkennbar am Erstellungsdatensatz oder an einem expliziten „Create“-Ereignis im Transaktionsprotokoll. Ereignistyp explicit | |||
| Zahlungsfehler erkannt | Zeigt an, dass das System zu einem bestimmten Zeitpunkt ein Problem mit der Zahlung erkannt hat, etwa ungültige Daten oder einen Compliance-Hinweis. Dieses Ereignis wird in der Regel ausdrücklich mit einem zugehörigen Fehlercode protokolliert. | ||
| Warum das wichtig ist Diese Aktivität ist der Ausgangspunkt für alle Analysen zu Nacharbeit und Ausnahmebehandlung. Sie ist für die Dashboards „Analyse von Zahlungsfehlern und Nacharbeit“ sowie „Zykluszeit der Fehlerbehebung“ unverzichtbar. Woher beziehen Suchen Sie nach ausdrücklichen Einträgen in einer Fehlerprotokolltabelle oder nach einer Statusänderung zu „Fehler“ oder „Korrektur erforderlich“ in der Transaktionstabelle. Verknüpfen Sie diese Ereignisse mit der Payment Transaction ID. Erfassung Ein ausdrückliches Ereignis wird protokolliert, wenn die Validierungs- oder Verarbeitungs-Engine des Systems einen Fehler meldet. Ereignistyp explicit | |||
| Zahlung abgeglichen | Bezeichnet den abschließenden Buchhaltungsschritt, bei dem die in ACI erfasste Zahlungstransaktion mit Kontoauszügen oder Hauptbucheinträgen abgeglichen wird. Dies kann als ausdrückliches Ereignis aus einem Abstimmungsmodul vorliegen oder aus einer Statusänderung abgeleitet werden. | ||
| Warum das wichtig ist Diese Aktivität misst die Effizienz des Abstimmungsprozesses im Backoffice. Verzögerungen können die Genauigkeit der Finanzberichterstattung beeinträchtigen und dazu führen, dass nicht abgerechnete Zahlungen unentdeckt bleiben. Woher beziehen Diese Informationen können aus einem eigenen Abstimmungsmodul in ACI oder einem externen ERP-System stammen. Erfasst werden sie beispielsweise durch eine Statusänderung des Zahlungsdatensatzes zu „Abgeglichen“. Erfassung Abgeleitet aus einer abschließenden Statusänderung zu „Abgeglichen“ oder aus Abstimmungsdaten, die über die Payment ID verknüpft werden. Ereignistyp inferred | |||
| Zahlung abgelehnt | Dieses Ereignis tritt ein, wenn eine freigebende Person die Zahlungsanforderung ablehnt. Häufig muss sie daraufhin korrigiert und erneut eingereicht werden. Das explizite Ereignis unterbricht den weiteren Ablauf der Zahlung und löst eine Nacharbeitsschleife aus. | ||
| Warum das wichtig ist Diese Aktivität macht Nacharbeit und Ineffizienzen im Prozess sichtbar. Wenn Sie die Häufigkeit von Ablehnungen verfolgen, können Sie Probleme mit der anfänglichen Datenqualität oder den Einreichungsrichtlinien erkennen und die Nacharbeit analysieren. Woher beziehen Wird als explizites Ereignis im Freigabeprotokoll oder als Statusänderung zu „Rejected“ in der Transaktionstabelle erfasst. Das Ereignis kann einen Ablehnungsgrund enthalten. Erfassung Wird erfasst, wenn eine freigebende Person die Ablehnung im System abschließt. Ereignistyp explicit | |||
| Zahlung bestätigt | Bezeichnet die interne Bestätigung, dass die Zahlung erfolgreich verarbeitet und eine Bestätigung empfangen wurde. Sie dient häufig als Auslöser für eine Benachrichtigung des Zahlungsempfängers oder anderer interner Systeme. | ||
| Warum das wichtig ist Dieser Meilenstein ist entscheidend, um die Einhaltung von Fälligkeitsterminen und die Quote pünktlicher Zahlungen zu messen. Er liefert einen eindeutigen Timestamp dafür, wann das Unternehmen die Zahlung als erfolgreich ausgeführt betrachtet. Woher beziehen Wird üblicherweise aus einer Statusänderung der Zahlungstransaktion zu „Confirmed“ oder „Completed“ abgeleitet, nachdem die Bestätigung des externen Netzwerks eingegangen ist. Erfassung Lässt sich aus einer Statusänderung zu „Confirmed“ oder „Processed“ ableiten. Ereignistyp inferred | |||
| Zahlung fehlgeschlagen | Ein Endstatus, der anzeigt, dass die Zahlung aufgrund eines nicht behebbaren Problems nicht abgeschlossen werden konnte. Er unterscheidet sich von einem behebbaren Fehler und kennzeichnet das endgültige Scheitern des Vorgangs. | ||
| Warum das wichtig ist Dieses Endereignis muss erfasst werden, um die Gesamtfehlerquote bei Zahlungen zu berechnen. Eine Analyse der Fehlerursachen kann dazu beitragen, die Datenqualität und die Prozessregeln zu verbessern. Woher beziehen Abgeleitet aus einem endgültigen Status wie „Fehlgeschlagen“, „Storniert“ oder „Von der Bank abgelehnt“ in den Transaktionsdaten, der sich anschließend nicht mehr ändert. Erfassung Abgeleitet aus einem endgültigen Fehlerstatus im Zahlungsdatensatz. Ereignistyp inferred | |||
| Zahlung zur Freigabe eingereicht | Zeigt an, dass die Zahlung die erste Validierung bestanden hat und zur erforderlichen Freigabe durch das Management oder die Finanzabteilung weitergeleitet wurde. Dies wird üblicherweise durch eine Statusänderung im Zahlungs-Workflow erfasst. | ||
| Warum das wichtig ist Damit beginnt der Freigabe-Teilprozess. Die Zeitspanne von diesem Zeitpunkt bis „Payment Approved“ ist eine wichtige Kennzahl für das Dashboard „Payment Approval Cycle Time Analysis“. Woher beziehen Lässt sich aus einer Änderung des Zahlungsstatus in den Transaktionsdaten ableiten, beispielsweise aus dem Wechsel zu „Pending Approval“. Erfassung Lässt sich an einer Statusänderung zu „Pending Approval“ oder einem ähnlichen Status sowie dem zugehörigen Timestamp erkennen. Ereignistyp inferred | |||
| Zahlungsanweisung gesendet | Kennzeichnet den Zeitpunkt, an dem die Zahlungsanweisung erstellt und an ein externes Zahlungsnetzwerk wie SWIFT, ACH oder SEPA übermittelt wird. ACI-Systeme protokollieren diese Übergabe ausdrücklich zu Prüf- und Nachverfolgungszwecken. | ||
| Warum das wichtig ist Bei vielen Zahlungsarten ist dies der letzte Punkt, an dem sich der Ablauf noch beeinflussen lässt. Die Nachverfolgung zeigt, wie lange die interne Verarbeitung dauert, bevor externe Abhängigkeiten den weiteren Ablauf bestimmen. Woher beziehen Dies ist fast immer ein explizites Ereignis in den Transaktions- oder Nachrichtenprotokollen von ACI und enthält häufig eine netzwerkspezifische Referenznummer. Erfassung Wenn die Zahlungsnachricht an das externe Netzwerk gesendet wird, wird ein expliziter Protokolleintrag erstellt. Ereignistyp explicit | |||
| Zahlungsdetails validiert | Diese Aktivität steht für den Abschluss automatisierter oder manueller Prüfungen, mit denen sichergestellt wird, dass Zahlungsdetails wie Angaben zum Zahlungsempfänger und Bankleitzahlen korrekt sind. Sie lässt sich häufig aus einer Statusänderung der Transaktion von „New“ zu „Validated“ oder „Pending Approval“ ableiten. | ||
| Warum das wichtig ist Diese Aktivität zeigt, wie effizient die ersten Schritte der Datenvalidierung ablaufen. Verzögerungen an dieser Stelle können vorgelagerte Engpässe verursachen und das Risiko späterer Zahlungsfehler erhöhen. Woher beziehen Lässt sich aus Statusänderungsfeldern in der zentralen Zahlungstransaktionstabelle ableiten. Vergleichen Sie die Timestamps des Status „Created“ mit einem späteren Status wie „Validated“. Erfassung Lässt sich aus einer Änderung des Zahlungsstatus ableiten, beispielsweise von „Entered“ zu „Validated“. Ereignistyp inferred | |||
| Zahlungsfehler behoben | Kennzeichnet den Zeitpunkt, zu dem ein Benutzer einen zuvor erkannten Fehler korrigiert und die Zahlung erneut zur Verarbeitung eingereicht hat. Häufig lässt sich dies an einer Statusänderung von einem Fehlerstatus zurück zu einem regulären Verarbeitungsstatus erkennen. | ||
| Warum das wichtig ist Mit dieser Aktivität wird die Ausnahmebehandlung abgeschlossen. Die Zeit zwischen „Zahlungsfehler erkannt“ und diesem Ereignis ist die Zykluszeit der Fehlerbehebung und ein wichtiger Maßstab für die operative Effizienz. Woher beziehen Abgeleitet aus einer Statusänderung von „Fehler“ zu einem Verarbeitungsstatus wie „Genehmigung ausstehend“ oder „Validiert“. Alternativ kann ein ausdrückliches Aktionsprotokoll des Benutzers vorliegen. Erfassung Abgeleitet aus einer Statusänderung weg von einem Fehlerstatus, die auf eine erfolgte Korrektur hinweist. Ereignistyp inferred | |||
Anleitungen zum Datenexport
Schritte
Zugriff auf die Datenbankumgebung: Melden Sie sich mit SQL Server Management Studio (SSMS) oder einem kompatiblen Client bei der SQL-Server-Instanz an, auf der die ACI-Postilion-Realtime-Datenbank gehostet wird.
Zentrale Tabellen ermitteln: Suchen Sie die Tabellen
post_tran(Transaktionsprotokoll) undpost_tran_cust(Erweiterung für benutzerdefinierte Daten). Stellen Sie sicher, dass Sie überSELECT-Berechtigungen für diese Objekte verfügen.Case-ID festlegen: Für diesen Export wird
retrieval_reference_nralsPaymentTransactionIdverwendet. Wenn Ihre Implementierung einen anderen eindeutigen Schlüssel nutzt, etwasystem_trace_audit_nrin Kombination mittransmission_date_time, passen Sie die Abfrage entsprechend an.Filterparameter festlegen: Öffnen Sie die Abfrage unten. Suchen Sie am Anfang des Skripts die Variablen
@StartDateund@EndDate. Legen Sie den gewünschten Exportzeitraum fest, zum Beispiel die letzten 30 bis 90 Tage, um die Leistung zu optimieren.Aktivitätslogik prüfen: Die Abfrage ordnet ISO-8583-Nachrichtentypen (z. B. 0200, 0210) und Antwortcodes den 14 erforderlichen Process-Mining-Aktivitäten zu. Prüfen Sie die
CASE-Anweisungen und stellen Sie sicher, dass sie zu Ihrer ACI-Schnittstellenkonfiguration passen.Abfrage ausführen: Führen Sie das vollständige Skript aus. Mit
UNION ALLvereinheitlicht die Abfrage unterschiedliche Transaktionsstatus in einem Event-Log-Format.Datenausgabe prüfen: Kontrollieren Sie, ob die erforderlichen Spalten vorhanden sind:
PaymentTransactionId,ActivityNameundEventTimestamp. Achten Sie darauf, dass kritische Felder nicht unerwartet den WertNULLenthalten.Daten exportieren: Klicken Sie im SSMS-Ergebnisraster mit der rechten Maustaste und speichern Sie die Ausgabe als CSV-Datei, zum Beispiel
ACI_Payments_EventLog.csv.Für ProcessMind formatieren: Öffnen Sie die CSV-Datei und prüfen Sie, ob
EventTimestampdem Standardformat YYYY-MM-DD HH:MM:SS entspricht undPaymentAmountausschließlich numerische Werte enthält.Upload: Importieren Sie die geprüfte CSV-Datei in ProcessMind und ordnen Sie die Spalten Case ID, Activity und Timestamp den entsprechenden Feldern zu.
Konfiguration
- Zeitraum: Die Tabellen
post_tranin ACI wachsen sehr schnell. Begrenzen Sie den Export nach Möglichkeit auf einen rollierenden Zeitraum von 3 Monaten oder verwenden Sie Partition Switching. - Antwortcodes: Die Abfrage geht davon aus, dass
rsp_code = '00'einen Erfolg kennzeichnet. Wenn Ihr Institut andere Codes für Genehmigung oder Erfolg verwendet, etwa '08' oder '10', passen Sie die Filter an. - Nachrichtentypen (ISO 8583): Das Skript verwendet die Standardnachrichtentypen (0100/0200 für Anfragen, 0210 für Antworten). Für benutzerdefinierte Nachrichtentypen in Ihrer Konfiguration von
source_node_namesind möglicherweise Anpassungen erforderlich. - Systemleistung: Die Abfrage verwendet
NOLOCK-Hinweise, um Sperren bei der laufenden Transaktionsverarbeitung zu vermeiden. Entfernen Sie diese Hinweise nicht in einer Produktionsumgebung. - Währungen: Beträge werden als Rohwerte exportiert. Wenn Sie die Währungen für die Analyse vereinheitlichen müssen, verwenden Sie
tran_currency_code.
a Beispielabfrage 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; Möchten Sie loslegen?
Verwenden Sie dieses Template als Leitfaden für den Export Ihrer Daten zur Zahlungsabwicklung. Gewinnen Sie wertvolle Erkenntnisse und verbessern Sie noch heute die Effizienz Ihrer Finanz-Workflows.
Zahlungsabwicklung verbessern: Starten Sie jetzt Ihre kostenlose Testphase
Vermeiden Sie Zahlungsausnahmen und erreichen Sie eine Dunkelverarbeitungsquote von 98 %.
Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.