Ihr Template für Zahlungsabwicklungsdaten
Ihr Template für Zahlungsabwicklungsdaten
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Extraktionsanleitung für ACI Worldwide
Zahlungsabwicklungs-Attribute
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivitätsname ActivityName | Der spezifische Schritt oder die Statusänderung, die im Zahlungslebenszyklus aufgetreten ist. | ||
| Beschreibung Dieses Attribut definiert den Event-Knoten in der Prozesskarte, wie z.B. 'Zahlungsanforderung erstellt' oder 'Gelder transferiert'. In ACI-Systemen wird dies oft aus Statuscodes, Audit Log-Operationstypen oder Workflow-Statusänderungen abgeleitet. Eine genaue Zuordnung dieser technischen Zustände zu lesbaren Geschäftsaktivitäten ist entscheidend für eine aussagekräftige Visualisierung. Bedeutung Es definiert den Prozessfluss und ist notwendig, um die Abfolge der Operationen zu visualisieren. Datenquelle Abgeleitet von Status Codes (z.B. 100=Erstellt, 200=Validiert) oder Audit Log Action-Spalten. Beispiele Zahlungsanforderung erstelltZahlung autorisiertZahlung beglichenZahlung fehlgeschlagen | |||
| Ereignis-Timestamp EventTimestamp | Das spezifische Datum und die Uhrzeit, wann die Aktivität stattfand. | ||
| Beschreibung Dieses Attribut erfasst den genauen Moment, in dem ein Event innerhalb der ACI-Umgebung stattfand. Es wird verwendet, um alle zeitbasierten Metriken zu berechnen, einschließlich Zykluszeiten, Genehmigungsdauern und Durchsatzraten. Eine hohe Präzision (Millisekunden) wird bevorzugt, um schnelle automatisierte Schritte genau zu sequenzieren. Bedeutung Essentiell für die Anordnung von Events und die Berechnung von Leistungsdauern. Datenquelle Konsultieren Sie die Spalten 'Created Date' oder 'Update Date' in den Transaktionshistorie- oder Audit-Tabellen. Beispiele 2023-10-25T08:30:15.000Z2023-10-25T08:30:22.500Z2023-10-26T14:10:00.000Z | |||
| Zahlungstransaktions-ID PaymentTransactionId | Der eindeutige Identifikator für die spezifische Zahlungsanweisung über das ACI-System hinweg. | ||
| Beschreibung Dieses Attribut dient als zentraler Schlüssel für die Process Mining-Analyse und verknüpft alle Events, die mit einer einzelnen Zahlungsanforderung zusammenhängen. In ACI Worldwide Systemen (wie MTS oder UPP) entspricht dies der eindeutigen Referenznummer, die einer Transaktion bei der Eingabe zugewiesen wird. Es ermöglicht die Rekonstruktion der End-to-End-Zahlungsreise von der ersten Anfrage über die Validierung und Genehmigung bis zur endgültigen Abrechnung. Bedeutung Es ist die grundlegende Case ID, die erforderlich ist, um diskrete Events zu Prozessinstanzen zu gruppieren. Datenquelle Prüfen Sie Transaktionskopf-Tabellen, oft als TRN_REF, REFERENCE_NUM oder UUID im Haupttransaktionsprotokoll bezeichnet. Beispiele TRX-2023-899102ACI-99281-AAPAY-0019283420231025-9981 | |||
| Abteilung Department | Die interne Abteilung, die für die aktuelle Aktivität zuständig ist. | ||
| Beschreibung Ordnet den Bedeutung Aggregiert die Leistung nach Geschäftsfunktion. Datenquelle Abgeleitet aus Benutzertabellen oder dem Mapping der Organisationshierarchie. Beispiele VorgängeComplianceTreasuryIT-Support | |||
| End-to-End Zykluszeit EndToEndCycleTime | Die Gesamtdauer von der Anforderungserstellung bis zur Abrechnung. | ||
| Beschreibung Berechnet die Zeitdifferenz zwischen 'Zahlungsanforderung erstellt' und 'Zahlung beglichen'. Dies dient als primäre Metrik für den KPI 'Durchschnittliche Zahlungs-Transaktionszykluszeit' und die allgemeine Effizienzanalyse. Bedeutung Die übergeordnete Metrik für die Prozessgeschwindigkeit. Datenquelle Berechnet: Timestamp(Payment Settled) - Timestamp(Payment Request Created). Beispiele 2 Tage 4 Stunden45 Minuten12 Sekunden | |||
| Ereignisbenutzer EventUser | Die Benutzer-ID oder der Systemagent, der für die Aktivität verantwortlich ist. | ||
| Beschreibung Erfasst, wer die Aktion durchgeführt hat – ob es sich um einen menschlichen Benutzer (z.B. für Genehmigungen) oder ein Systemkonto (z.B. für die automatisierte Abrechnung) handelte. Dieses Attribut ist entscheidend für die 'Bottleneck Analysis', um festzustellen, ob bestimmte Benutzer oder Warteschlangen überlastet sind. Bedeutung Ermöglicht Ressourcenanalyse und Prüfung der Funktionstrennung (Segregation of Duties). Datenquelle Audit Logs oder 'UpdatedBy'-Spalten in Transaktionstabellen. Beispiele SYSTEM_AGENT_01j.doeapprover_group_aBATCH_PROCESS | |||
| Fehlercode ErrorCode | Der Code, der generiert wird, wenn eine Zahlung fehlschlägt oder eine Reparatur erfordert. | ||
| Beschreibung Erfasst den spezifischen Grund für ein 'Payment Failed' oder 'Payment Error Identified' Event. Die Gruppierung nach diesem Attribut im Dashboard 'Payment Failure and Rework Analysis' ermöglicht es dem Unternehmen, die häufigsten Ursachen für Fehler (z.B. 'Unzureichende Deckung', 'Ungültiges Konto') zu identifizieren. Bedeutung Essentiell für die Root Cause Analysis von Prozessfehlern. Datenquelle Fehlerprotokolle oder Statusgrundspalten, oft REASON_CODE oder RETURN_CODE. Beispiele R01AM04BE05TECH_ERR_001 | |||
| Ist Nacharbeit IsRework | Flag, das anzeigt, ob die Zahlung wiederholte Aktivitäten durchlaufen hat. | ||
| Beschreibung Ein boolesches Flag, das während der Datenverarbeitung berechnet wird. Es wird auf 'true' gesetzt, wenn Aktivitäten wie 'Payment Details Validated' mehr als einmal auftreten oder wenn eine Fehlerschleife erkannt wird. Dies steuert den KPI 'Payment Rework Rate'. Bedeutung Identifiziert schnell ineffiziente Datenquelle Wird in der Datenpipeline durch Überprüfung auf doppelte Aktivitäten pro Case berechnet. Beispiele truefalsch | |||
| Verarbeitungskanal ProcessingChannel | Der Kanal, über den die Zahlung initiiert wurde. | ||
| Beschreibung Zeigt den Eintrittspunkt der Zahlung an, z.B. Mobile, Webportal, API oder Datei-Upload. Dies hilft bei der 'Payment Process Variant Analysis', um zu sehen, ob bestimmte Kanäle anfälliger für Fehler oder Verzögerungen sind als andere. Bedeutung Segmentiert die Leistung nach Eingabemethode. Datenquelle Transaktionskopf, oft in Spalten namens CHANNEL, SOURCE_TYPE oder INPUT_METHOD. Beispiele SWIFTInternet-BankingMobile AppDatei-Upload | |||
| Zahlungsart PaymentType | Die Klassifizierung des Zahlungsinstruments. | ||
| Beschreibung Kategorisiert die Zahlung (z.B. Überweisung, ACH, SEPA, RTGS). Verschiedene Zahlungsarten haben oft sehr unterschiedliche SLAs und Prozessabläufe. Dieses Attribut ist eine primäre Dimension für die Filterung des Dashboards 'End-to-End Payment Cycle Time'. Bedeutung Entscheidend für die Unterscheidung zwischen Hochgeschwindigkeits- und Batch-Zahlungsflüssen. Datenquelle Transaktionskopf, Felder wie PMT_TYPE, INSTRUMENT_TYPE oder SERVICE_ID. Beispiele InlandsüberweisungAuslandsüberweisungACH CreditSofortzahlung | |||
| Zahlungsbetrag PaymentAmount | Der monetäre Wert der Zahlungstransaktion. | ||
| Beschreibung Zeigt den finanziellen Wert der Überweisung an. Dies ist ein kritisches Kontextfeld für die Analyse des 'Payments Throughput' und die Priorisierung von Bottlenecks. Hochwertige Zahlungen durchlaufen oft strengere Genehmigungspfade (Variantenanalyse) im Vergleich zu automatisierten Zahlungsflüssen mit geringem Wert. Bedeutung Ermöglicht die Segmentierung nach Wert und die Berechnung des gesamten verarbeiteten Volumens. Datenquelle Transaktionsdetailtabellen, typischerweise Felder wie AMT, TRANS_AMOUNT oder PRINCIPAL_AMOUNT. Beispiele 1500.00250000.5050.001000000.00 | |||
| Zahlungsfälligkeitsdatum PaymentDueDate | Das Datum, bis zu dem die Zahlung beglichen sein muss, um als pünktlich zu gelten. | ||
| Beschreibung Speichert das vertragliche oder angeforderte Ausführungsdatum. Dieses Datum wird mit dem tatsächlichen Abrechnungsdatum verglichen, um die KPI 'Pünktliche Zahlungsrate' zu berechnen und das Dashboard 'Zahlungsfristen-Compliance' zu unterstützen. Bedeutung Die Benchmark zur Messung der SLA-Compliance und der pünktlichen Leistung. Datenquelle Transaktionsanweisungen, üblicherweise VALUE_DATE, EXECUTION_DATE oder DUE_DATE. Beispiele 2023-11-012023-11-05 | |||
| Zahlungswährung PaymentCurrency | Der ISO-Währungscode für den Zahlungsbetrag. | ||
| Beschreibung Gibt die Währung an, in der der Bedeutung Erforderlich, um den Zahlungsbetrag korrekt zu interpretieren. Datenquelle Transaktionsdetailtabellen, typischerweise Felder wie CCY, CURRENCY_CODE oder ISO_CODE. Beispiele USDEURGBPJPY | |||
| Abstimmungs-ID ReconciliationId | Identifikator, der die Zahlung mit dem Hauptbuch oder dem Abstimmungsdatensatz verknüpft. | ||
| Beschreibung Diese ID wird ausgefüllt, wenn die Aktivität 'Zahlung abgestimmt' stattfindet. Sie stellt sicher, dass die Zahlung in der Verarbeitungs-Engine mit dem Eintrag im Buchhaltungssystem übereinstimmt. Das Fehlen dieser ID bei abgewickelten Zahlungen weist auf Abstimmungsfehler hin. Bedeutung Entscheidend für das Dashboard 'Payment Reconciliation Efficiency'. Datenquelle Abstimmungstabellen oder spezifische Felder wie RECON_REF oder GL_REF. Beispiele REC-9921GL-Entry-2023-11 | |||
| Freigabe-Durchlaufzeit ApprovalCycleTime | Dauer in der Genehmigungsphase. | ||
| Beschreibung Berechnet die Zeit zwischen 'Zahlung zur Genehmigung gesendet' und 'Zahlung genehmigt' (oder abgelehnt). Diese spezifische Metrik fließt in das Dashboard 'Payment Approval Cycle Time Analysis' ein und hebt Verzögerungen in menschlichen Entscheidungsschritten hervor. Bedeutung Isoliert den vom Menschen abhängigen Teil des Prozesses. Datenquelle Berechnet: Timestamp(Payment Approved) - Timestamp(Payment Sent For Approval). Beispiele 4 Stunden15 Minuten | |||
| Ist Zahlung verspätet IsPaymentLate | Flag, das anzeigt, ob die Zahlung nach dem Fälligkeitsdatum beglichen wurde. | ||
| Beschreibung Ein boolesches Flag, das das tatsächliche Abrechnungsdatum mit dem Bedeutung Vereinfacht das Compliance-Reporting. Datenquelle Berechnet: SettlementDate > PaymentDueDate. Beispiele truefalsch | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, wann der Datensatz zuletzt im Datenmodell extrahiert oder aktualisiert wurde. | ||
| Beschreibung Verfolgt die Aktualität der in der Analyse verwendeten Daten. Dies stellt keine Prozess-Event-Zeit dar, sondern die technische Zeit der Datenaufnahme. Es stellt sicher, dass Analysten wissen, ob sie sich Echtzeit- oder historische Snapshots ansehen. Bedeutung Stellt die Aktualität der Daten sicher und hilft, veraltete Daten in Dashboards zu identifizieren. Datenquelle Systemzeit zum Zeitpunkt der ETL-Skriptausführung. Beispiele 2023-10-27T00:00:00.000Z2023-10-27T12:00:00.000Z | |||
| Name des Begünstigten BeneficiaryName | Der Name der Entität, die die Zahlung erhält. | ||
| Beschreibung Identifiziert den Transaktionspartner. Die Analyse dieses Feldes kann dabei helfen, bestimmte Anbieter oder Kunden zu identifizieren, die mit hohen Nacharbeitsraten oder Verzögerungen verbunden sind, und unterstützt die 'Payment Failure and Rework Analysis'. Bedeutung Identifiziert das Ziel der Zahlung, nützlich für eine kundenorientierte Analyse. Datenquelle Zahlungsdetails, Felder wie CREDITOR_NAME, BENE_NAME oder PAYEE. Beispiele Acme CorpGlobal Supplies LtdJohn Smith | |||
| Quellsystem SourceSystem | Der Name des Systems, in dem die Event-Daten entstanden sind. | ||
| Beschreibung Identifiziert die spezifische Anwendung oder das Modul innerhalb des ACI Worldwide Ökosystems (z.B. ACI MTS, ACI UPF) oder externe Systeme, die am Flow beteiligt sind. Dies ist besonders wichtig beim Zusammenführen von Daten über mehrere Hauptbücher hinweg oder wenn die Zahlung externe Clearingstellen berührt. Bedeutung Bietet Kontext dazu, wo Daten extrahiert wurden, nützlich für das Debugging der Datenherkunft. Datenquelle Hardcodiert während der Extraktion oder abgeleitet von einer SystemID-Spalte, wenn mehrere Instanzen existieren. Beispiele ACI MTSACI UPPSAP GLSwift Gateway | |||
| Ursprungsregion OriginatingRegion | Die geografische Region, in der die Zahlungsanforderung entstand. | ||
| Beschreibung Zeigt den physischen oder logischen Standort des Anfragenden an. Dies ist nützlich für die 'Payment Process Variant Analysis', um zu sehen, ob bestimmte Regionen nicht-standardisierte Pfade verfolgen oder höhere Ablehnungsraten aufweisen. Bedeutung Bietet geografischen Kontext zur Prozessleistung. Datenquelle Transaktionskopf, oft abgeleitet von Filialcode oder Ländercode. Beispiele NordamerikaEMEAAPAC | |||
Zahlungsabwicklungs-Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Gelder überwiesen | Zeigt an, dass eine Bestätigung vom Zahlungsnetzwerk eingegangen ist, dass Gelder erfolgreich vom Zahlerkonto abgebucht wurden. Dies wird normalerweise aus einer eingehenden Statusnachricht des Netzwerks erfasst. | ||
| Bedeutung Bestätigt die erfolgreiche Ausführung der Zahlung durch das externe Netzwerk. Es markiert den Beginn der Abrechnungsperiode und ist ein wichtiger Input für den KPI 'Durchschnittliche Zahlungsabrechnungszeit'. Datenquelle Dies ist ein explizites Event, das durch eine eingehende Statusaktualisierungsnachricht (z.B. MT103 von SWIFT oder eine ACH-Bestätigung) ausgelöst wird, die den Zahlungsdatensatz aktualisiert. Erfassen Protokolliert bei Erhalt einer externen Bestätigungsnachricht vom Clearing-Netzwerk. Ereignistyp explicit | |||
| Zahlung autorisiert | Stellt die systemseitige Autorisierung der Zahlung nach menschlicher Genehmigung dar, wobei Gelder überprüft oder gegen Betrugsregeln geprüft werden. Dies kann ein expliziter Protokolleintrag oder eine aus einer Statusänderung abgeleitete Bereitschaft zur Ausführung sein. | ||
| Bedeutung Dies ist ein kritischer Kontrollpunkt, bevor Gelder angewiesen werden. Verzögerungen in dieser Phase können auf Systemleistungsprobleme oder Probleme mit Compliance- und Betrugsprüfungs-Subsystemen hinweisen. Datenquelle Suchen Sie nach einem expliziten Protokoll in einem Systemverarbeitungs- oder Sicherheitsprotokoll. Alternativ kann es aus einer Statusaktualisierung von 'Approved' zu 'Authorized for Payment' abgeleitet werden. Erfassen Vom Zahlungs-Engine des Systems protokolliert, nachdem die letzten internen Prüfungen bestanden wurden. Ereignistyp explicit | |||
| Zahlung beglichen | Die endgültige Bestätigung, dass der Zahlungsprozess abgeschlossen und die Gelder dem Zahlungsempfänger gutgeschrieben wurden, womit die Transaktion beendet ist. Dies ist ein kritisches Event, das das erfolgreiche Ende des Zahlungslebenszyklus darstellt. | ||
| Bedeutung Dies ist das primäre Erfolgs-End-Event für den Prozess. Es wird verwendet, um die Gesamtzykluszeit und den Durchsatz zu berechnen, und ist für nahezu alle End-to-End-Performance-Dashboards unerlässlich. Datenquelle Typischerweise ein explizites Event, das protokolliert wird, wenn eine finale Abrechnungsbestätigungsnachricht vom Netzwerk empfangen wird oder wenn das interne Ledger aktualisiert wird, um den Abschluss der Transaktion widerzuspiegeln. Erfassen Protokolliert bei Erhalt einer endgültigen Abrechnungsdatei oder -nachricht, aktualisiert den Status auf 'Beglichen'. Ereignistyp explicit | |||
| Zahlung genehmigt | Ein wichtiger Meilenstein, bei dem ein autorisierter Benutzer die Zahlung genehmigt und diese zur Ausführung freigibt. Dies wird in der Regel als explizites Event erfasst, wenn der Genehmiger eine Aktion in der Benutzeroberfläche des Systems ausführt. | ||
| Bedeutung Diese Aktivität ist ein wichtiger Kontrollpunkt und oft ein signifikanter Engpass. Die Analyse der Wartezeiten vor diesem Schritt und der Dauer des Genehmigungszyklus hilft, Möglichkeiten zur Beschleunigung von Zahlungen zu identifizieren. Datenquelle Suchen Sie nach einem expliziten Event in einer Genehmigungsprotokoll-Tabelle oder einer Statusänderung zu 'Approved' in der Haupttransaktionstabelle, die mit einer spezifischen Benutzeraktion und einem Timestamp verknüpft ist. Erfassen Protokolliert, wenn ein autorisierter Benutzer die Genehmigungsaktion im System abschließt. Ereignistyp explicit | |||
| Zahlungsanforderung erstellt | Diese Aktivität markiert die Initiierung einer neuen Zahlungstransaktion innerhalb des ACI Worldwide Systems. Es ist typischerweise ein explizites Event, das aufgezeichnet wird, wenn ein Benutzer oder ein vorgelagertes System eine Zahlungsanforderung übermittelt und einen neuen Transaktionsdatensatz mit einer eindeutigen ID erstellt. | ||
| Bedeutung Dies ist das primäre Start-Event für den Zahlungsprozess. Die Analyse der Zeit von dieser Aktivität bis zum Abschluss liefert die End-to-End-Zykluszeit, die für die Messung der gesamten Prozesseffizienz unerlässlich ist. Datenquelle Dies ist wahrscheinlich ein explizites Event, das in der Kern-Transaktionstabelle oder einem dedizierten Event Log in ACI protokolliert wird. Suchen Sie nach einem Erstellungs-Timestamp, der mit der Zahlungs-Transaktions-ID verknüpft ist. Erfassen Identifiziert durch den Erstellungsdatensatz oder ein explizites 'Erstellen'-Event im Transaktionsprotokoll. Ereignistyp explicit | |||
| Zahlungsfehler identifiziert | Zeigt an, dass das System in einem bestimmten Stadium ein Problem mit der Zahlung erkannt hat, z.B. ungültige Daten oder eine Compliance-Warnung. Dieses Event wird typischerweise explizit mit einem zugehörigen Fehlercode protokolliert. | ||
| Bedeutung Diese Aktivität ist der Ausgangspunkt für alle Nacharbeits- und Ausnahmebehandlungsanalysen. Sie ist essenziell für die Dashboards 'Analyse von Zahlungsausfällen und Nacharbeit' und 'Fehlerbehebungszykluszeit'. Datenquelle Suchen Sie nach expliziten Einträgen in einer Fehlerprotokoll-Tabelle oder einer Statusänderung zu 'Error' oder 'Requires Correction' in der Transaktionstabelle. Diese Events sollten mit der Payment Transaction ID verknüpft sein. Erfassen Ein explizites Event wird protokolliert, wenn die Validierungs- oder Verarbeitungsengine des Systems einen Fehler meldet. Ereignistyp explicit | |||
| Zahlung abgelehnt | Tritt auf, wenn ein Genehmiger die Zahlungsanforderung ablehnt, was oft eine Korrektur und erneute Einreichung erfordert. Dies ist ein explizites Event, das den Fortschritt der Zahlung stoppt und eine Nacharbeitsschleife einleitet. | ||
| Bedeutung Identifiziert Nacharbeiten und Prozessineffizienzen. Die Verfolgung der Häufigkeit von Ablehnungen hilft, Probleme mit der anfänglichen Datenqualität oder den Einreichungsrichtlinien zu diagnostizieren und unterstützt die Nacharbeitsanalyse. Datenquelle Wird als explizites Event im Genehmigungsprotokoll oder als Statusänderung zu 'Rejected' in der Transaktionstabelle erfasst. Das Event kann einen Ursachencode für die Ablehnung enthalten. Erfassen Protokolliert, wenn ein Genehmiger die Ablehnungsaktion im System abschließt. Ereignistyp explicit | |||
| Zahlung abgestimmt | Stellt den letzten Buchungsschritt dar, bei dem die in ACI erfasste Zahlungstransaktion mit Bankauszügen oder Hauptbucheinträgen abgeglichen wird. Dies kann ein explizites Event aus einem Abstimmungsmodul oder eine abgeleitete Statusänderung sein. | ||
| Bedeutung Diese Aktivität misst die Effizienz des Back-Office-Abstimmungsprozesses. Verzögerungen hier können die Genauigkeit der Finanzberichterstattung beeinträchtigen und unbeglichene Zahlungsprobleme verdecken. Datenquelle Diese Informationen könnten aus einem dedizierten Abstimmungsmodul innerhalb von ACI oder einem externen ERP-System stammen. Sie würden über eine Statusaktualisierung auf 'Abgestimmt' im Zahlungsdatensatz erfasst. Erfassen Abgeleitet von einer finalen 'Abgestimmt'-Statusaktualisierung oder von Abstimmungsdaten, die nach Payment ID verknüpft sind. Ereignistyp inferred | |||
| Zahlung bestätigt | Stellt die interne Bestätigung dar, dass die Zahlung erfolgreich verarbeitet und eine Bestätigung empfangen wurde. Dies dient oft als Auslöser für die Benachrichtigung des Zahlungsempfängers oder anderer interner Systeme. | ||
| Bedeutung Dieser Meilenstein ist entscheidend für die Messung der Fälligkeits-Compliance und der Pünktlichen Zahlungsrate. Er liefert einen klaren Timestamp dafür, wann die Organisation die Zahlung als erfolgreich ausgeführt betrachtet. Datenquelle Dies wird typischerweise aus einer Statusänderung in der Zahlungstransaktionstabelle zu einem 'Bestätigt'- oder 'Abgeschlossen'-Status abgeleitet, nachdem eine externe Netzwerkbestätigung empfangen wurde. Erfassen Abgeleitet von einer Statusänderung zu 'Bestätigt' oder 'Verarbeitet'. Ereignistyp inferred | |||
| Zahlung fehlgeschlagen | Ein Endstatus, der anzeigt, dass die Zahlung aufgrund eines nicht behebbaren Problems nicht abgeschlossen werden konnte. Dies unterscheidet sich von einem behebbaren Fehler und stellt einen definitiven Endzustand des Fehlers dar. | ||
| Bedeutung Die Verfolgung dieses End-Events ist entscheidend für die Berechnung der gesamten Zahlungsausfallrate. Die Analyse der Fehlerursachen kann dazu beitragen, die Datenqualität und Prozessregeln zu verbessern. Datenquelle Abgeleitet von einem finalen, terminierenden Status wie 'Failed', 'Cancelled' oder 'Rejected by Bank' in den Transaktionsdaten, der sich danach nicht mehr ändert. Erfassen Abgeleitet von einem terminalen Fehlerstatus im Zahlungsdatensatz. Ereignistyp inferred | |||
| Zahlung zur Genehmigung gesendet | Zeigt an, dass die Zahlung die initiale Validierung bestanden hat und zur erforderlichen Management- oder Finanzgenehmigung weitergeleitet wurde. Dies wird typischerweise durch eine Statusänderung innerhalb des Zahlungs-Workflows erfasst. | ||
| Bedeutung Dies markiert den Beginn des Genehmigungs-Subprozesses. Die Messung der Zeit von diesem Punkt bis 'Payment Approved' ist entscheidend für das Dashboard 'Payment Approval Cycle Time Analysis'. Datenquelle Abgeleitet aus einer Änderung im Zahlungsstatusfeld der Transaktionsdaten, z.B. dem Übergang zu 'Pending Approval'. Erfassen Abgeleitet von einer Statusänderung zu 'Pending Approval' oder Ähnlichem, zusammen mit einem entsprechenden Timestamp. Ereignistyp inferred | |||
| Zahlungsanweisung gesendet | Markiert den Zeitpunkt, an dem die Zahlungsanweisung kompiliert und an ein externes Zahlungsnetzwerk wie SWIFT, ACH oder SEPA übermittelt wird. ACI-Systeme protokollieren diese Übergabe explizit für Audit- und Nachverfolgungszwecke. | ||
| Bedeutung Dies ist der 'Point of no Return' für viele Zahlungsarten. Die Verfolgung hilft, die interne Verarbeitungszeit zu messen, bevor externe Abhängigkeiten übernehmen. Datenquelle Dies ist fast immer ein explizites Event, das in ACI's Transaktions- oder Messaging-Logs protokolliert wird, oft einschließlich einer netzwerkspezifischen Referenznummer. Erfassen Ein expliziter Protokolleintrag wird erstellt, wenn die Zahlungsnachricht an das externe Netzwerk gesendet wird. Ereignistyp explicit | |||
| Zahlungsdetails validiert | Stellt den Abschluss automatischer oder manueller Prüfungen dar, um sicherzustellen, dass Zahlungsdetails wie Empfängerinformationen und Bankleitzahlen korrekt sind. Diese Aktivität wird oft aus einer Statusänderung der Transaktion von 'Neu' zu 'Validiert' oder 'Genehmigung ausstehend' abgeleitet. | ||
| Bedeutung Verfolgt die Effizienz der anfänglichen Datenvalidierungsschritte. Verzögerungen hier können vorgelagerte Engpässe verursachen und die Wahrscheinlichkeit von Zahlungsfehlern später im Prozess erhöhen. Datenquelle Abgeleitet aus Statusänderungsfeldern in der Haupttabelle der Zahlungs Transaktionen. Vergleichen Sie Timestamps zwischen dem Status 'Erstellt' und einem nachfolgenden Status wie 'Validiert' oder ähnlichem. Erfassen Abgeleitet aus einer Änderung im Zahlungsstatusfeld, z.B. von 'Eingegeben' zu 'Validiert'. Ereignistyp inferred | |||
| Zahlungsfehler behoben | Markiert den Zeitpunkt, an dem ein zuvor identifizierter Fehler von einem Benutzer korrigiert und die Zahlung erneut zur Bearbeitung eingereicht wird. Dies wird oft abgeleitet, wenn sich der Status einer Zahlung von einem Fehlerzustand zurück in einen normalen Verarbeitungszustand ändert. | ||
| Bedeutung Diese Aktivität schließt die Ausnahmeschleife. Die Zeit zwischen 'Zahlungsfehler identifiziert' und diesem Event ist die Fehlerbehebungszykluszeit, ein Schlüsselmaß für die operative Effizienz. Datenquelle Abgeleitet aus einer Statusänderung weg von einem 'Fehler'-Zustand hin zu einem Verarbeitungszustand wie 'Pending Approval' oder 'Validated'. Es kann auch ein explizites Benutzeraktionsprotokoll sein. Erfassen Abgeleitet von einer Statusänderung aus einem Fehlerzustand, die anzeigt, dass eine Korrektur vorgenommen wurde. Ereignistyp inferred | |||
Extraktionsleitfäden
Schritte
Zugriff auf die Datenbankumgebung: Melden Sie sich mit SQL Server Management Studio (SSMS) oder einem kompatiblen Client bei der SQL Server-Instanz an, die die ACI Postilion Realtime-Datenbank hostet.
Identifizieren Sie die Kerntabellen: Suchen Sie die Tabellen
post_tran(Transaktionsprotokoll) undpost_tran_cust(benutzerdefinierte Datenerweiterung). Stellen Sie sicher, dass SieSELECT-Berechtigungen für diese Objekte besitzen.Bestimmen Sie den Fallidentifikator: Diese Extraktion verwendet die
retrieval_reference_nrals diePaymentTransactionId. Falls Ihre Implementierung einen anderen eindeutigen Schlüssel verwendet (wiesystem_trace_audit_nrin Kombination mittransmission_date_time), passen Sie die Abfrageauswahl entsprechend an.Filterparameter konfigurieren: Öffnen Sie die unten bereitgestellte Abfrage. Suchen Sie die Variablen
@StartDateund@EndDateoben im Skript. Legen Sie diese auf Ihr gewünschtes Extraktionsfenster fest (z.B. die letzten 30 bis 90 Tage), um die Leistung zu optimieren.Aktivitätslogik überprüfen: Die Abfrage ordnet ISO 8583-Nachrichtentypen (z.B. 0200, 0210) und Antwortcodes den erforderlichen 14 Process Mining-Aktivitäten zu. Überprüfen Sie die
CASE-Anweisungen, um sicherzustellen, dass sie mit Ihren spezifischen ACI-Schnittstellenkonfigurationen übereinstimmen.Abfrage ausführen: Führen Sie das vollständige Skript aus. Die Abfrage verwendet
UNION ALL, um verschiedene Transaktionszustände in ein einheitliches Event Log-Format zu normalisieren.Daten-Output überprüfen: Prüfen Sie die Ergebnisse auf die erforderlichen Spalten:
PaymentTransactionId,ActivityNameundEventTimestamp. Stellen Sie sicher, dass keine kritischen Felder unerwartetNULL-Werte enthalten.Daten exportieren: Klicken Sie mit der rechten Maustaste auf das Ergebnisraster in SSMS und speichern Sie die Ausgabe als CSV-Datei (z.B.
ACI_Payments_EventLog.csv).Formatierung für ProcessMind: Öffnen Sie die CSV-Datei und überprüfen Sie, ob der
EventTimestampin einem Standardformat (JJJJ-MM-TT HH:MM:SS) vorliegt und dassPaymentAmountnur numerische Werte enthält.Hochladen: Importieren Sie die überprüfte CSV-Datei in ProcessMind und ordnen Sie die Spalten entsprechend Case ID, Activity und Timestamp zu.
Konfiguration
- Datumsbereich: ACI
post_tranTabellen wachsen sehr schnell. Es wird dringend empfohlen, die Extraktion auf ein rollierendes 3-Monats-Fenster zu beschränken oder bei Verfügbarkeit Partition Switching zu verwenden. - Antwortcodes: Die Abfrage geht davon aus, dass
rsp_code = '00'Erfolg anzeigt. Falls Ihre Institution andere Codes für Genehmigung/Erfolg verwendet (z.B. '08' oder '10'), aktualisieren Sie die Filter. - Nachrichtentypen (ISO 8583): Das Skript basiert auf Standard-Nachrichtentypen (0100/0200 für Anfragen, 0210 für Antworten). Benutzerdefinierte Nachrichtentypen, die in Ihrer
source_node_nameKonfiguration definiert sind, erfordern möglicherweise Anpassungen. - Systemleistung: Diese Abfrage verwendet
NOLOCK-Hinweise, um das Blockieren der Live-Transaktionsverarbeitung zu verhindern. Entfernen Sie diese Hinweise in einer Produktionsumgebung nicht. - Währungen: Beträge werden als Rohdaten extrahiert. Stellen Sie sicher, dass
tran_currency_codeverwendet wird, falls eine Multi-Währungs-Normalisierung während der Analyse erforderlich ist.
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;