> Kontinuierliche Prozessverbesserung > Zahlungsabwicklung > FIS Global > Daten Template

Ihr Daten-Template für die Zahlungsabwicklung

FIS Global

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute der Zahlungsabwicklung (19) Aktivitäten der Zahlungsabwicklung (13) Anleitungen zur Datenextraktion (1)

Ihr Daten-Template für die Zahlungsabwicklung

Dieses Template erläutert die wesentlichen Datenattribute und Prozessaktivitäten, die Sie für eine aussagekräftige Analyse der Zahlungsabwicklung benötigen. Außerdem erfahren Sie, wie Sie diese wichtigen Informationen aus Ihren Systemen extrahieren. So stellen Sie sicher, dass alle erforderlichen Daten für Ihr Process-Mining-Vorhaben erfasst werden.

Empfohlene Attribute für die Datenerfassung
Wichtige Aktivitäten für die Nachverfolgung
Anleitung zur Datenextraktion

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute der Zahlungsabwicklung

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um die Zahlungsabwicklung umfassend zu analysieren.

3 Erforderlich 7 Empfohlen 9 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name des jeweiligen Prozessschritts oder eingetretenen Ereignisses.
Beschreibung Dieses Feld erfasst die konkrete Aktion zu einem bestimmten Zeitpunkt, etwa „Zahlungsanfrage erstellt“ oder „Zahlung abgewickelt“. Es definiert die Knoten in der Prozesslandkarte und bestimmt die Struktur des Prozessablaufs. Analysten verwenden dieses Attribut, um die Reihenfolge der Vorgänge nachzuvollziehen. Es ist entscheidend, um Abweichungen vom Happy Path zu erkennen, übersprungene Schritte aufzudecken oder überflüssige Aktivitäten wie mehrere Freigabeschleifen zu identifizieren. Warum das wichtig ist Es beschreibt, was im Prozess geschieht, und ermöglicht die Visualisierung von Prozesslandkarten sowie die Analyse von Varianten. Woher beziehen Dokumentation von FIS Global konsultieren Beispiele Zahlungsanfrage erstelltZahlungsdetails validiertZahlung genehmigtZahlung abgewickelt
	Ereignis-Timestamp EventTimestamp	Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat.
Beschreibung Dieses Attribut liefert den zeitlichen Kontext für jedes Ereignis im Zahlungsprozess. Es erfasst den genauen Zeitpunkt, zu dem das System eine Aktion protokolliert hat, und ermöglicht so die chronologische Sortierung der Aktivitäten. In der Analyse dient es dazu, die Dauer zwischen Prozessschritten, die gesamte Zykluszeit und den Durchsatz zu berechnen. Verzögerungen zwischen bestimmten Prozessphasen machen Engpässe sichtbar. Warum das wichtig ist Ohne dieses Feld ist eine zeitbasierte Analyse nicht möglich. Es bildet die Grundlage für alle Leistungs- und Effizienz-KPIs. Woher beziehen Dokumentation von FIS Global konsultieren Beispiele 2023-10-12T08:30:15Z2023-10-12T09:45:00Z2023-10-13T14:20:10Z
	ID der Zahlungstransaktion PaymentTransactionId	Der eindeutige Bezeichner für die jeweilige Zahlungsanweisung oder Transaktion.
Beschreibung Dieses Attribut ist der zentrale Schlüssel, über den alle Ereignisse eines Zahlungslebenszyklus verknüpft werden. Es ermöglicht Analysten, den Weg der Zahlung von der ersten Anfrage über Validierung und Freigabe bis zur endgültigen Abwicklung oder zum Abgleich nachzuverfolgen. In der Analyse werden mit dieser ID einzelne Ereignisse zu Prozessinstanzen gruppiert. So lässt sich der Ablauf von Anfang bis Ende visualisieren. Außerdem bildet sie die Grundlage für alle Kennzahlen auf Case-Ebene, etwa die Zykluszeit und Nachbearbeitungsschleifen. Warum das wichtig ist Sie ist das grundlegende Verknüpfungsmerkmal für Process Mining und ermöglicht es, einzelne Aktivitäten zu einem zusammenhängenden Ablauf zusammenzuführen. Woher beziehen Dokumentation von FIS Global konsultieren Beispiele TRX-2023-899102PAY-US-99281ACH-7721-X99WIRE-2210-001
	Geschäftseinheit BusinessUnit	Der interne Geschäftsbereich oder die Abteilung, von der die Zahlung ausgeht.
Beschreibung Dieses Attribut ordnet die Zahlung einer bestimmten Organisationseinheit zu, etwa dem Privatkundengeschäft, der gewerblichen Kreditvergabe oder dem Treasury. Damit lassen sich KPIs wie „Zahlungsdurchsatz“ und „Durchschnittliche Zahlungszykluszeit“ nach Abteilung aufschlüsseln. Das Management kann so die Leistung verschiedener Geschäftsbereiche vergleichen und Ressourcen gezielt zuweisen. Warum das wichtig ist Es ermöglicht interne Leistungsvergleiche und schafft Verantwortlichkeit für die Prozessleistung. Woher beziehen Dokumentation von FIS Global konsultieren Beispiele TreasuryKreditorenbuchhaltungPrivatkundengeschäftVermögensverwaltung
	Tatsächliches Abwicklungsdatum ActualSettlementDate	Das Datum, an dem die Zahlung tatsächlich abgeschlossen und abgewickelt wurde.
Beschreibung Dieses Attribut erfasst das tatsächliche Datum der Geldüberweisung oder des Abschlusses der Transaktion. Anders als der Verarbeitungs-Timestamp gibt es das Wertstellungsdatum an. In der Analyse wird es zusammen mit dem Fälligkeitsdatum verwendet, um die „Pünktlichkeitsquote der Zahlungen“ zu berechnen. Es löst außerdem die Abgleichsphase aus und ist daher für die Analyse der „Zahlungsabgleichszykluszeit“ wichtig. Warum das wichtig ist Es kennzeichnet den finanziellen Abschluss der Zahlung und ist eine wichtige Grundlage für die Cashflow-Analyse. Woher beziehen Dokumentation von FIS Global konsultieren Beispiele 2023-11-022023-11-14
	Verarbeitender Benutzer ProcessingUser	Der Bezeichner oder Name des Benutzers beziehungsweise Systemagenten, der die Aktivität ausführt.
Beschreibung Dieses Attribut erfasst, wer oder was den Prozessschritt ausgeführt hat. Es unterscheidet zwischen menschlichen Bearbeitern (z. B. „J.Smith“) und automatisierten Systemkonten (z. B. „SYSTEM_BATCH“). Diese Daten dienen dazu, die Ressourcenauslastung zu analysieren, manuelle Engpässe zu erkennen und die Funktionstrennung zu prüfen. Sie unterstützen die Berechnung der „Auslastungsquote verarbeitender Benutzer“ und die Unterscheidung zwischen manuellen und automatisierten Aufgaben. Warum das wichtig ist Unverzichtbar für die Ressourcenanalyse, die Ermittlung des Automatisierungsgrads und Compliance-Prüfungen. Woher beziehen Dokumentation von FIS Global konsultieren Beispiele jsmithSYSTEM_AUTOBOTmdoe_approverAPI_GATEWAY
	Währungscode CurrencyCode	Der dreistellige ISO-Code der Zahlungswährung.
Beschreibung Dieses Attribut gibt die Währung des Zahlungsbetrags an (z. B. USD, EUR, GBP). Es ist unverzichtbar, um Finanzdaten bei der Analyse globaler Zahlungsströme zu vereinheitlichen. In der Analyse ermöglicht dieses Feld, die Prozessleistung nach Währung aufzuschlüsseln. Die Währung hängt häufig mit unterschiedlichen Clearingsystemen und Vorschriften zusammen. So lassen sich Unterschiede bei den Abwicklungszeiten grenzüberschreitender und inländischer Zahlungen erklären. Warum das wichtig ist In Umgebungen mit mehreren Währungen ist dieses Attribut entscheidend, um Finanzvolumen korrekt einzuordnen. Woher beziehen Dokumentation von FIS Global konsultieren Beispiele USDEURGBPJPY
	Zahlungsart PaymentType	Die Klassifizierung der Zahlungsmethode oder des Zahlungsinstruments.
Beschreibung Dieses Attribut ordnet Zahlungen Kategorien wie Überweisung, ACH, SEPA, Echtzeitzahlung (RTP) oder Scheck zu. Für die verschiedenen Zahlungsarten gelten jeweils eigene Verarbeitungsregeln und SLAs. Analysten verwenden dieses Feld, um die „Zahlungsabgleichszykluszeit“ für unterschiedliche Zahlungswege zu vergleichen. Es erklärt, warum manche Zahlungen sofort abgewickelt werden, während andere mehrere Tage dauern, und stellt sicher, dass die Leistung anhand des passenden Vergleichswerts beurteilt wird. Warum das wichtig ist Es ist die zentrale Dimension für die Segmentierung von Prozessabläufen, da jede Zahlungsart eigene Routing- und Zeitmerkmale aufweist. Woher beziehen Dokumentation von FIS Global konsultieren Beispiele ÜberweisungACH-GutschriftSEPA-EchtzeitüberweisungScheck
	Zahlungsbetrag PaymentAmount	Der Geldbetrag der Zahlungstransaktion.
Beschreibung Dieses Attribut gibt den finanziellen Wert der Zahlungsanfrage an. Es ist die zentrale Kennzahl für die Analyse des finanziellen Durchsatzes und des Risikos. Analysten verwenden dieses Feld, um Prozesse nach hohen und niedrigen Zahlungsbeträgen zu segmentieren, da dafür häufig unterschiedliche Freigabewege gelten. Es unterstützt das Dashboard „Zahlungsdurchsatz“ und zeigt, ob Zahlungen mit hohen Beträgen aufgrund strengerer Prüfungen längere Zykluszeiten haben. Warum das wichtig ist Es ergänzt Process Mining um die finanzielle Dimension und ermöglicht eine Priorisierung nach Zahlungswert. Woher beziehen Dokumentation von FIS Global konsultieren Beispiele 1500.00250.501000000.0045.99
	Zahlungsfälligkeitsdatum PaymentDueDate	Das Datum, bis zu dem die Zahlung voraussichtlich abgewickelt sein soll.
Beschreibung Dieses Attribut erfasst die Zahlungsfrist, die der Auftraggeber vorgibt oder die sich aus den Rechnungsbedingungen ergibt. Sie dient als Vergleichswert für die Pünktlichkeit. Das Feld ist entscheidend für das Dashboard „Einhaltung der Zahlungstermine“. Durch den Vergleich mit dem tatsächlichen Datum der Zahlungsabwicklung können Analysten verspätete Zahlungen kennzeichnen, mögliche Vertragsstrafen berechnen und die Einhaltung von Lieferantenvereinbarungen beurteilen. Warum das wichtig ist Es bildet die Grundlage, um die Einhaltung von Service-Level-Vorgaben und die Pünktlichkeit zu messen. Woher beziehen Dokumentation von FIS Global konsultieren Beispiele 2023-11-012023-11-15
	Absenderkonto SenderAccount	Die Kontonummer, von der der Betrag abgebucht wird.
Beschreibung Dieses Attribut gibt das Ursprungskonto der Transaktion an. Es ermöglicht eine detaillierte Analyse von Zahlungen, die über bestimmte interne Konten abgewickelt werden. In der Analyse hilft es festzustellen, ob bestimmte Finanzierungskonten häufiger Fehler wie eine unzureichende Deckung oder Verzögerungen aufweisen. Beim Abgleich unterstützt es die Zuordnung von Hauptbucheinträgen zu Prozessaktivitäten. Warum das wichtig ist Es ist eine wichtige Grundlage für den Finanzabgleich und die Analyse von Problemen auf Kontoebene. Woher beziehen Dokumentation von FIS Global konsultieren Beispiele 123456789987654321ACC-TREASURY-01
	Empfängerland BeneficiaryCountry	Der Ländercode des Zahlungsempfängers.
Beschreibung Dieses Attribut gibt das Zielland der Geldüberweisung an. Damit lassen sich inländische und internationale Zahlungen unterscheiden. Dieser Kontext ist wichtig für die „Überwachung der Zahlungskonformität“ und die Analyse des Routings. Bei internationalen Zahlungen sind häufig andere Intermediäre und Compliance-Prüfungen beteiligt; zudem dauern sie oft länger. Eine Auswertung nach Ländern hilft, diese Faktoren getrennt zu betrachten. Warum das wichtig ist Es ist eine wichtige Dimension für geografische Analysen und die Bewertung von Compliance-Risiken. Woher beziehen Dokumentation von FIS Global konsultieren Beispiele USDECNGB
	Freigabeberechtigung ApprovalAuthority	Die Rolle, Gruppe oder Person, die für die Autorisierung der Zahlung verantwortlich ist.
Beschreibung Dieses Attribut gibt an, welche Berechtigungsstufe oder Benutzergruppe die Zahlung freigeben muss. Die erforderliche Freigabe richtet sich häufig nach dem Zahlungsbetrag. Das Attribut hilft, den Verlauf des Freigabe-Workflows nachzuvollziehen. Analysten verwenden es für das Dashboard „Engpässe bei der Zahlungsautorisierung“. Damit lassen sich Freigabezeiten nach Berechtigungsstufe aufschlüsseln und Verzögerungen durch bestimmte Führungsebenen erkennen. Warum das wichtig ist Es ermöglicht die Analyse der Freigabehierarchie und das Erkennen organisatorischer Engpässe. Woher beziehen Dokumentation von FIS Global konsultieren Beispiele Manager der Ebene 1CFOCompliance-TeamSystem für automatische Freigaben
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp, zu dem der Datensatz zuletzt extrahiert oder aktualisiert wurde.
Beschreibung Dieses Attribut zeigt, wie aktuell die für die Analyse verwendeten Daten sind. Benutzer können damit erkennen, ob sie Echtzeitdaten oder einen Snapshot aus einem früheren Zeitraum betrachten. In Dashboards wird dieses Feld häufig für den Hinweis „Datenstand“ verwendet. Es unterstützt Entscheidungen auf Grundlage der aktuellsten verfügbaren Informationen und erleichtert die Verwaltung inkrementeller Datenladungen. Warum das wichtig ist Es gibt Auskunft über den Aktualitätsstand der Daten und stärkt das Vertrauen in die zeitnahe Berichterstattung. Woher beziehen Metadaten des ETL-Prozesses Beispiele 2023-10-14T00:00:00Z2023-10-15T06:00:00Z
	Manueller Eingriff IsManualIntervention	Ein Kennzeichen dafür, ob die Aktivität manuelle Arbeit erforderte.
Beschreibung Dieses boolesche Attribut kennzeichnet Aktivitäten oder Cases, für die menschliches Eingreifen erforderlich war, etwa „Zahlungsfehler behoben“ oder manuelle Freigaben. Es unterscheidet diese von der durchgängigen automatisierten Verarbeitung (STP). Das Attribut ist entscheidend für das Dashboard „Quote manueller Eingriffe bei Zahlungen“. Es zeigt, welcher Anteil der Zahlungen nicht vollständig automatisiert ist, und macht Ansatzpunkte für die digitale Transformation sichtbar. Warum das wichtig ist Es unterscheidet automatisierten Durchsatz von manuellem Aufwand und unterstützt die Berechnung des ROI von Automatisierungsvorhaben. Woher beziehen Abgeleitet aus ActivityName oder ProcessingUser Beispiele truefalse
	Quellsystem SourceSystem	Der Name des Systems, aus dem die Ereignisdaten stammen.
Beschreibung Dieses Attribut gibt an, aus welcher Softwarekomponente oder Datenbank der Datensatz extrahiert wurde, etwa aus dem Kernbankensystem, dem Zahlungsgateway oder dem Sanktionsprüfsystem. Es ist wichtig für die Datenherkunft und Validierung. Bei der Analyse durchgängiger Abläufe über mehrere Plattformen hinweg zeigt dieses Feld, wo bestimmte Aktivitäten stattgefunden haben, und erleichtert die Behebung von Problemen mit der Datenqualität. Warum das wichtig ist Es gewährleistet Rückverfolgbarkeit und Kontext, insbesondere in komplexen Umgebungen mit mehreren integrierten Zahlungssystemen. Woher beziehen Dokumentation von FIS Global konsultieren Beispiele FIS OPFTraxPaymentHub_01SanctionsScreeningDB
	Validierungsfehlercode ValidationErrorCode	Der Code oder Grund dafür, dass eine Zahlung die Validierung nicht bestanden hat.
Beschreibung Dieses Attribut wird ausgefüllt, wenn die Zahlung die Aktivität „Zahlungsfehler erkannt“ erreicht. Es enthält genaue Angaben zum Fehler, etwa „Ungültige IBAN“, „Unzureichende Deckung“ oder „Empfängeradresse fehlt“. Dieses Feld fließt in das Dashboard „Fehlerquoten bei der Validierung von Zahlungsdaten“ ein. Eine Gruppierung nach diesem Attribut zeigt die häufigsten Ursachen für Nachbearbeitung und ermöglicht gezielte Korrekturen bei der vorgelagerten Dateneingabe oder der Systemkonfiguration. Warum das wichtig ist Es macht die Ursachen für Prozessprobleme und Nachbearbeitungsschleifen sichtbar. Woher beziehen Dokumentation von FIS Global konsultieren Beispiele ERR-001: Ungültiges KontoERR-055: SanktionslistentrefferERR-009: Doppelte Transaktion
	Verspätete Zahlung IsLatePayment	Ein Kennzeichen dafür, ob die Zahlung nach dem Fälligkeitsdatum abgewickelt wurde.
Beschreibung Dieses boolesche Attribut wird berechnet. Es gibt „true“ zurück, wenn das Datum der Zahlungsabwicklung nach dem Zahlungsfälligkeitsdatum liegt. Dieses Attribut fließt direkt in den KPI „Pünktlichkeitsquote der Zahlungen“ ein. Es vereinfacht die Arbeit mit Dashboards, da Benutzer problematische Cases schnell filtern können, ohne in der Visualisierung komplexe Datumslogik einzurichten. Warum das wichtig ist Es vereinfacht die Berichterstattung zu Ausnahmen und die Compliance-Analyse. Woher beziehen Abgeleitet aus PaymentDueDate und ActualSettlementDate Beispiele truefalse
	Zahlungskanal PaymentChannel	Der Kanal, über den die Zahlungsanfrage eingeleitet wurde.
Beschreibung Dieses Attribut beschreibt, woher die Zahlungsanweisung stammt, etwa aus dem Onlinebanking, einer mobilen App, einer API oder einer Filiale. Es gibt Aufschluss darüber, über welchen Weg die Transaktion erfasst wurde. Analysten vergleichen damit die Verarbeitungseffizienz verschiedener Kanäle. So lässt sich beispielsweise feststellen, ob Zahlungen über eine API seltener fehlerhaft sind als manuell in einer Filiale erfasste Zahlungen. Warum das wichtig ist Es unterstützt die Optimierung der Kanäle und die Analyse des Kundenverhaltens. Woher beziehen Dokumentation von FIS Global konsultieren Beispiele OnlinebankingMobile AppUnternehmensgatewayFilialmitarbeiter

Erforderlich Empfohlen Optional

Aktivitäten der Zahlungsabwicklung

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um Prozesse zuverlässig zu entdecken und zu verbessern.

6 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Zahlung abgeglichen	Bei dieser abschließenden Buchhaltungsaktivität wird die Zahlungstransaktion einem Kontoauszug oder einem internen Hauptbucheintrag zugeordnet. Der Abgleich kann automatisiert im Stapelverfahren oder manuell durch einen Benutzer erfolgen.
Warum das wichtig ist Diese Aktivität markiert das endgültige Ende des Zahlungslebenszyklus. Die Analyse der „Zahlungsabgleichszykluszeit“ ist entscheidend, um die Effizienz des Finanzabschlusses zu beurteilen. Woher beziehen Wird häufig daraus abgeleitet, dass das Feld „reconciliation_date“ ausgefüllt ist oder sich der abschließende Status in einem mit dem Zahlungssystem verknüpften Finanz- oder Buchhaltungsmodul in „Abgeglichen“ ändert. Erfassung Erkennbar daran, dass ein Abgleichsdatum eingetragen oder der Status in „Abgeglichen“ geändert wird. Ereignistyp inferred
	Zahlung abgewickelt	Diese Aktivität kennzeichnet den Abschluss der Geldüberweisung. Die Transaktion gilt damit als finanziell abgewickelt. Üblicherweise wird sie erfasst, sobald das Zahlungsnetzwerk oder die Clearingstelle eine abschließende Abwicklungsbestätigung sendet.
Warum das wichtig ist Dieser Endpunkt ist maßgeblich für die Messung der Zahlungszykluszeit und der Pünktlichkeitsquote. Er kennzeichnet den erfolgreichen Abschluss des eigentlichen Zahlungsvorgangs. Woher beziehen Wird aus einer abschließenden Statusänderung des Zahlungsvorgangs in „Abgewickelt“, „Abgeschlossen“ oder „Gebucht“ abgeleitet. Die Statusänderung wird durch Abwicklungsdateien aus der Stapelverarbeitung oder Echtzeitnachrichten des Clearingsystems ausgelöst. Erfassung Der Status der Zahlungstransaktion ändert sich in „Abgewickelt“ oder einen entsprechenden Status. Ereignistyp inferred
	Zahlung autorisiert	Diese abschließende Autorisierung ist häufig bei Zahlungen mit hohem Betrag oder nach der ersten Freigabe durch eine weitere zuständige Stelle erforderlich. Sie wird als explizites Ereignis erfasst, wenn ein Benutzer mit den entsprechenden Berechtigungen die Zahlung bestätigt.
Warum das wichtig ist Diese Aktivität ist entscheidend für das Dashboard „Engpässe bei der Zahlungsautorisierung“. Wenn sie getrennt von „Zahlung genehmigt“ erfasst wird, lassen sich Verzögerungen bei mehrstufigen Freigaben genauer erkennen. Woher beziehen Wird in einem Prüf- oder Transaktionsprotokoll erfasst. Das Ereignis wird ausgelöst, wenn ein Benutzer mit speziellen Autorisierungsrechten die Zahlung bearbeitet. Dabei werden seine ID und ein Timestamp protokolliert. Erfassung Wenn ein Benutzer die abschließende Autorisierung ausführt, wird ein expliziter Protokolleintrag erstellt. Ereignistyp explicit
	Zahlung genehmigt	Ein wichtiger Meilenstein: Ein berechtigter Benutzer genehmigt die Zahlung, damit sie den nächsten Schritt durchlaufen kann. Fast immer wird diese Aktion als explizites Ereignis mit der ID des Genehmigenden und einem Timestamp protokolliert.
Warum das wichtig ist Dieser wichtige Kontrollpunkt dient dazu, Freigabezeiten zu messen und die Einhaltung finanzieller Kontrollen sicherzustellen. Verzögerungen in dieser Phase können die pünktliche Abwicklung von Zahlungen erheblich beeinträchtigen. Woher beziehen Wird in einer Freigabeprotokolltabelle oder als explizites Ereignis im Verlauf der Haupttransaktion erfasst. Das Event Log verknüpft die Zahlungstransaktions-ID mit der Benutzer-ID des Genehmigenden und dem Freigabe-Timestamp. Erfassung Wird protokolliert, wenn ein Benutzer mit Freigabeberechtigung die Aktion „Genehmigen“ für eine Zahlung ausführt. Ereignistyp explicit
	Zahlungsanfrage erstellt	Dies ist das erste Ereignis im Zahlungslebenszyklus. Es markiert den Zeitpunkt, an dem im FIS-System eine neue Zahlungstransaktion gestartet wird. In der Regel wird es als expliziter Eintrag in einer Transaktionsprotokolltabelle erfasst, wenn ein Benutzer oder ein automatisiertes System eine neue Zahlungsanfrage übermittelt.
Warum das wichtig ist Diese Aktivität markiert den eindeutigen Prozessbeginn. Sie ist wichtig, um die Durchlaufzeit des gesamten Zahlungsprozesses sowie den Gesamtdurchsatz und das Transaktionsvolumen zu messen. Woher beziehen Der Eintrag befindet sich in einer zentralen Transaktionstabelle und wird anhand des Erstellungs-Timestamps zur Zahlungstransaktions-ID identifiziert. Suchen Sie in Tabellen wie „Payment_Transactions“ oder „Payment_Requests“ nach einem Feld wie „creation_date“ oder „entry_date“. Erfassung Ereignis, das beim Erstellen eines neuen Zahlungstransaktionsdatensatzes protokolliert wird. Ereignistyp explicit
	Zahlungsanweisung gesendet	Diese Aktivität markiert den Zeitpunkt, an dem das FIS-System die endgültige Zahlungsanweisung an das zuständige Zahlungsnetzwerk sendet, zum Beispiel ACH, Fedwire oder SWIFT. Es handelt sich um ein wichtiges, vom System erzeugtes Ereignis.
Warum das wichtig ist Dieser wichtige Meilenstein zeigt an, dass die Zahlung die interne Verarbeitungsumgebung verlassen hat. Er ist entscheidend für die Analyse der Weiterleitungseffizienz und der Dauer der externen Verarbeitung. Woher beziehen Wird in einem Transaktions- oder Nachrichtenprotokoll erfasst, das die Mitteilungen an externe Zahlungsnetzwerke dokumentiert. Suchen Sie nach einem Eintrag, der eine erfolgreiche ausgehende Nachrichtenübermittlung mit Timestamp ausweist. Erfassung Vom System erzeugtes Ereignis, wenn die Zahlungsnachricht an das Clearing-Netzwerk gesendet wird. Ereignistyp explicit
	Verspätete Zahlung erkannt	Ein abgeleitetes Ereignis, das anzeigt, dass die Zahlung nach dem festgelegten Fälligkeitsdatum abgewickelt wurde. Diese Aktivität wird nicht ausdrücklich protokolliert, sondern durch den Vergleich zweier Datumsfelder berechnet.
Warum das wichtig ist Diese berechnete Aktivität fließt direkt in den KPI „Pünktlichkeitsquote der Zahlungen“ und das Dashboard „Einhaltung der Zahlungstermine“ ein. Sie hilft, die Auswirkungen von Prozessverzögerungen auf Lieferantenbeziehungen und mögliche Verzugsgebühren zu beziffern. Woher beziehen Dieses Ereignis wird nicht direkt aus den Daten extrahiert. Bei der Datentransformation wird der Timestamp des Felds „Abwicklungsdatum“ mit dem Feld „Zahlungsfälligkeitsdatum“ verglichen. Liegt das Abwicklungsdatum nach dem Fälligkeitsdatum, wird das Ereignis erzeugt. Erfassung Wird berechnet, wenn „Abwicklungsdatum“ > „Zahlungsfälligkeitsdatum“. Ereignistyp calculated
	Zahlung abgelehnt	Diese Aktivität tritt ein, wenn ein Genehmigender eine Zahlungsanfrage ablehnt. Die Anfrage muss dann in der Regel korrigiert und erneut eingereicht oder vollständig storniert werden. Die Benutzeraktion wird zu Prüfzwecken protokolliert.
Warum das wichtig ist Die Erfassung von Ablehnungen hilft, häufige Ursachen für fehlgeschlagene Zahlungen, Prozessabweichungen und Nacharbeitsschleifen zu erkennen. Sie macht Probleme mit der anfänglichen Datenqualität oder der Compliance sichtbar. Woher beziehen Wird als explizites Ereignis in einem Freigabe- oder Transaktionsverlaufsprotokoll erfasst, wenn ein Genehmigender die Option „Ablehnen“ auswählt. Der Datensatz enthält üblicherweise einen Timestamp, die Benutzer-ID und häufig auch einen Ablehnungsgrund. Erfassung Ereignis, das protokolliert wird, wenn ein Benutzer die Aktion „Ablehnen“ für eine Zahlung ausführt. Ereignistyp explicit
	Zahlung bestätigt	Bezeichnet den Eingang einer Bestätigung des Zahlungsnetzwerks oder der Empfängerbank, dass die Zahlung eingegangen ist. Ausgelöst wird dieses Ereignis durch eine eingehende Systemnachricht oder eine Statusaktualisierung.
Warum das wichtig ist Die Bestätigung zeigt, dass die Zahlung ihr Ziel erreicht hat. Die Zeit zwischen „Zahlungsanweisung gesendet“ und „Bestätigt“ misst die Latenz des externen Netzwerks und die Bearbeitungszeit. Woher beziehen Wird durch das Auslesen eingehender Bestätigungsnachrichten von Zahlungsnetzwerken erzeugt. Das System aktualisiert den Zahlungsstatus und erfasst einen Bestätigungs-Timestamp. Erfassung Eine eingehende Nachricht eines Clearing-Netzwerks setzt den Zahlungsstatus auf „Bestätigt“. Ereignistyp explicit
	Zahlung zur Freigabe eingereicht	Diese Aktivität markiert den Zeitpunkt, an dem eine validierte Zahlung in den Freigabe-Workflow übermittelt wird. In der Regel wird sie durch eine Statusänderung erfasst, die anzeigt, dass die Zahlung auf die Freigabe wartet.
Warum das wichtig ist Diese Aktivität markiert den Beginn des Freigabe-Teilprozesses. Die Zeitspanne zwischen diesem Ereignis und „Zahlung genehmigt“ ist entscheidend, um Engpässe bei Freigaben zu erkennen. Woher beziehen Lässt sich aus einer Änderung des Zahlungsstatus zu „Freigabe ausstehend“, „Zur Freigabe eingereicht“ oder einem ähnlichen Status in einem Workflow- oder Transaktionsstatusprotokoll ableiten. Erfassung Statusänderung der Zahlungstransaktion von „Validiert“ zu „Freigabe ausstehend“. Ereignistyp inferred
	Zahlungsdetails validiert	Diese Aktivität zeigt an, dass die Zahlungsdaten die ersten automatisierten Prüfungen auf Format, Vollständigkeit und Korrektheit bestanden haben. Häufig lässt sie sich aus einer Statusänderung des Zahlungsdatensatzes ableiten, zum Beispiel von „Neu“ zu „Validiert“ oder „Freigabe ausstehend“.
Warum das wichtig ist Die Erfassung dieser Aktivität hilft, Häufigkeit und Ort von Dateneingabefehlern zu ermitteln. Sie ist Voraussetzung für die Analyse der KPI „Fehlerquote bei der Validierung von Zahlungsdaten“ und für das Verständnis der Ursachen von Nacharbeit. Woher beziehen Lässt sich aus einem Status- oder Zustandsänderungsfeld in der Zahlungstransaktionstabelle ableiten. Eine Änderung vom Ausgangszustand zu „validiert“ markiert zusammen mit dem zugehörigen Timestamp dieses Ereignis. Erfassung Erkennbar an einer Änderung des Zahlungsstatusfelds zu „Validiert“ oder einem ähnlichen Wert. Ereignistyp inferred
	Zahlungsfehler behoben	Kennzeichnet die Behebung eines zuvor erkannten Zahlungsfehlers. Anschließend kann die Zahlung erneut verarbeitet oder storniert werden. Ein Benutzer setzt den Ausnahmestatus dabei ausdrücklich zurück.
Warum das wichtig ist Diese Aktivität schließt die Ausnahmeschleife. Die Zeit zwischen „Fehler erkannt“ und diesem Ereignis ist eine wichtige Kennzahl für die Effizienz der Ausnahmebehandlung. Woher beziehen Wird protokolliert, wenn ein Benutzer eine Fehlermeldung zurücksetzt oder die Transaktion aus einer Ausnahmewarteschlange entfernt. Die Aktion wird mit Timestamp in einem Audit-Trail oder im Transaktionsverlauf erfasst. Erfassung Ein Benutzer setzt den Fehlerstatus zurück. Die Aktion wird in einem Audit-Protokoll erfasst. Ereignistyp explicit
	Zahlungsfehler erkannt	Zeigt an, dass nach der ersten Validierung ein Fehler im Prozess erkannt wurde, etwa eine Ablehnung durch die Empfängerbank oder ein interner Compliance-Hinweis. Häufig wird dieses Ereignis ausdrücklich protokolliert, wenn eine Ausnahme ausgelöst wird.
Warum das wichtig ist Diese Aktivität ist der Einstiegspunkt für alle Nachbearbeitungs- und Ausnahmebehandlungsschleifen. Sie ist entscheidend für die Berechnung der KPIs „Manuelle Eingriffsquote“ und „Bearbeitungszeit zur Behebung von Zahlungsfehlern“. Woher beziehen Wird in einem Modul zur Ausnahmebehandlung oder im Transaktionsprotokoll erfasst. Ausgelöst werden kann das Ereignis automatisch durch eine Systemregel oder manuell, wenn ein Benutzer ein Problem meldet. Dabei wird ein Protokolleintrag mit Fehlercode und Timestamp angelegt. Erfassung Für die Zahlungstransaktion wird ein Ausnahme- oder Fehlercode protokolliert. Ereignistyp explicit

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus FIS Global

Schritte

Prüfen Sie, ob die Zahlungs-Engine von FIS Global unverarbeitete ISO-20022-XML-Nachrichten archiviert, darunter Zahlungsanweisungen vom Typ pacs.008 und Zahlungsstatusmeldungen vom Typ pacs.002. Ermitteln Sie den zugänglichen Archivpfad, das Dateinamensschema, die Namespace-Konfiguration, die Aufbewahrungsdauer sowie die Zuordnung zwischen der Zahlungs-Transaktions-ID und ISO-20022-Kennungen wie EndToEndId, TxId, InstrId oder UETR.
Installieren Sie Python 3.10 oder höher sowie die vom Skript verwendeten Standardbibliotheksmodule, darunter pathlib, xml.etree.ElementTree, csv, datetime, decimal und collections. Die Referenzimplementierung benötigt keine externen Pakete. Stellen Sie sicher, dass das ausführende Benutzerkonto XML-Dateien aus dem Archiv lesen und die ProcessMind-Ausgabedatei schreiben kann.
Konfigurieren Sie im Skript das Eingabeverzeichnis, die Ausgabedatei, das Start- und Enddatum, die Zeitzone sowie unternehmensspezifische Filter. Ersetzen Sie nur die dokumentierten Platzhalter. Gehen Sie nicht davon aus, dass ein Dateiname oder XML-Element die ProcessMind-Case-ID enthält, bevor Sie die Zuordnung anhand repräsentativer Dateien geprüft haben.
Prüfen Sie repräsentative pacs.008- und pacs.002-Dateien zu erfolgreichen, abgelehnten, fehlgeschlagenen, korrigierten und abgewickelten Transaktionen. Bestätigen Sie die XML-Namespaces und ermitteln Sie die Elemente mit Transaktionskennung, Betrag, Währung, angefordertem Ausführungsdatum, Abwicklungsdatum, Statuscode, Ursachencode, Ereigniszeitstempel, verarbeitendem Benutzer oder Systemagenten, Zahlungsart und Geschäftseinheit. Passen Sie die konfigurierten XPath-Kandidaten an, wenn Ihre FIS-Implementierung andere Pfade verwendet.
Führen Sie das Skript zunächst für einen begrenzten Zeitraum aus. Der Parser liest jede XML-Datei, extrahiert Daten auf Nachrichten- und Transaktionsebene, ordnet ISO-20022-Status- und Ursachencodes konkreten Aktivitäten zu und schreibt für jede extrahierte Aktivität eine Ereigniszeile. Außerdem erzeugt das Skript die Zeilen „Zahlungsfehler erkannt“ und „Zahlungsfehler behoben“, wenn explizite Fehler- oder Korrekturindikatoren vorliegen. „Verspätete Zahlung erkannt“ wird nur dann erzeugt, wenn die Abwicklung nach dem Fälligkeitsdatum erfolgte.
Prüfen Sie die erzeugte CSV-Datei und den Validierungsbericht. Stellen Sie sicher, dass PaymentTransactionId, ActivityName und EventTimestamp in jeder Zeile ausgefüllt sind, alle 13 erforderlichen Aktivitätsnamen vorkommen können und die Zeitstempel einheitlich normalisiert sind. Untersuchen Sie Transaktionen mit fehlenden Kennungen, nicht unterstützten Statuscodes, doppelten Ereignissen oder widersprüchlichen Datumsangaben, bevor Sie den Extraktionszeitraum erweitern.
Gleichen Sie die Ereignisanzahl mit dem Quellarchiv und, sofern verfügbar, mit FIS-Betriebsberichten oder Prüfprotokollextrakten ab. Prüfen Sie eine Stichprobe von Transaktionen durchgängig, einschließlich Freigabe, Ablehnung, Autorisierung, Versand der Zahlungsanweisung, Netzwerkbestätigung, Abwicklung, Fehlerbehandlung, Abstimmung und Erkennung verspäteter Zahlungen. Bewahren Sie bei Bedarf für die betriebliche Nachverfolgbarkeit den Quelldateinamen sowie die Quellzeile oder Nachrichtenreferenz in der Prüfdatenausgabe auf.
Planen Sie die Ausführung des Skripts nach Abschluss des Quellarchivs für den ausgewählten Zeitraum. Alternativ können Sie es schrittweise mit einem kontrollierten Überlappungszeitraum ausführen, um verspätet eintreffende pacs.002-Nachrichten zu erfassen. Entfernen Sie Duplikate anhand von PaymentTransactionId, ActivityName, EventTimestamp und der Identität der Quellnachricht. Erhalten Sie dabei legitime Wiederholungen von Aktivitäten, wenn die Quelle mehrere Vorkommen enthält.
Exportieren Sie das fertige Event Log als UTF-8-CSV-Datei mit einer Zeile pro Ereignis und den Spalten PaymentTransactionId, ActivityName, EventTimestamp, ProcessingUser, PaymentAmount, CurrencyCode, PaymentType, PaymentDueDate, ActualSettlementDate und BusinessUnit. Laden Sie die Datei in ProcessMind hoch und legen Sie PaymentTransactionId als Case-ID, ActivityName als Aktivität und EventTimestamp als Ereigniszeitstempel fest. ProcessMind liest das Event Log unverändert ein und leitet keine fehlenden Aktivitäten ab.

Konfiguration

Pfad zum Eingabearchiv: Geben Sie das Verzeichnis mit den unverarbeiteten ISO-20022-XML-Dateien an. Beziehen Sie alle relevanten Unterverzeichnisse ein, wenn das Archiv nach Datum, Unternehmen, Nachrichtentyp oder Verarbeitungsstatus aufgeteilt ist.
Nachrichtentypen: Berücksichtigen Sie pacs.008 für Zahlungsanweisungen und pacs.002 für Zahlungsstatusmeldungen. Nehmen Sie weitere Nachrichtentypen erst auf, nachdem ihre Kennungen und Statusbedeutungen in der FIS-Implementierung geprüft wurden.
Kennungszuordnung: Konfigurieren Sie die XPath-Kandidaten, über die sich die Zahlungs-Transaktions-ID ermitteln lässt. Bevorzugen Sie die Kennung, die im FIS-Transaktionsdatensatz und in allen zugehörigen ISO-20022-Nachrichten einheitlich verwendet wird. Verknüpfen Sie keine nicht zusammengehörigen Kennungen ohne dokumentierte Korrelationsregel.
Aktivitätszuordnung: Konfigurieren Sie die Zuordnung von Status- und Ursachencodes für Erstellung, Validierung, Einreichung zur Freigabe, Freigabe, Ablehnung, Autorisierung, Versand der Zahlungsanweisung, Bestätigung, Abwicklung, Fehlererkennung, Fehlerbehebung und Abstimmung. Das bereitgestellte Skript verwendet konfigurierbare Zuordnungen und explizite Quellindikatoren. Gewöhnliche Ereignisse im Prozessverlauf werden nicht aus fehlenden Datensätzen abgeleitet.
Zeitraum: Beginnen Sie mit 3 bis 6 Monaten an Daten. Verwenden Sie für erste Tests oder Archive mit hohem Datenvolumen einen kürzeren Zeitraum. Berücksichtigen Sie einen Überlappungszeitraum, wenn Statusmeldungen nach dem ursprünglichen Zahlungsdatum eintreffen können.
Datumsfilter: Legen Sie Start- und Enddatum anhand des Zeitstempels des Quellereignisses fest, sofern dieser verfügbar ist. Fehlt einer Nachricht ein Ereigniszeitstempel, kann das Skript nur dann den Änderungszeitstempel der Datei verwenden, wenn diese Option ausdrücklich aktiviert ist. Dokumentieren Sie diese Ausweichlösung, da sie keinen Zeitstempel eines Geschäftsereignisses darstellt.
Filter für Unternehmen und Organisationseinheiten: Konfigurieren Sie Filter für Unternehmen, Geschäftseinheit, Rechtsträger, Zahlungsprodukt oder Dokumenttyp nur, wenn die entsprechenden XML-Elemente vorhanden und ihre Werte geprüft sind. Verwenden Sie für implementierungsspezifische Filter [Configure based on your system].
Zeitzone: Legen Sie die Zeitzone des Quellsystems oder die Normalisierung auf UTC fest. Wenden Sie dieselbe Regel auf alle Nachrichten an, damit die Ereignisreihenfolge zuverlässig bleibt.
Fehler- und Korrekturindikatoren: Konfigurieren Sie die Statuscodes, Ursachencodes und expliziten Korrektur- oder Ausnahmeindikatoren, die „Zahlungsfehler erkannt“ und „Zahlungsfehler behoben“ kennzeichnen. Ordnen Sie nicht jede Ablehnung als Fehler ein, sofern dies nicht der freigegebenen fachlichen Definition entspricht.
Abstimmungsindikatoren: Konfigurieren Sie den in der FIS-Implementierung verwendeten expliziten Abstimmungsstatus, die Abstimmungsnachricht, den Hauptbuch-Abgleichsindikator oder das Batchergebnis. Wenn die Abstimmung außerhalb des XML-Archivs gespeichert wird, geben Sie eine separate freigegebene Quelle und Korrelationsregel an.
Leistung: Verarbeiten Sie die Dateien schrittweise, statt das gesamte Archiv in den Arbeitsspeicher zu laden. Teilen Sie umfangreiche Läufe nach Datum oder Verzeichnis auf, schreiben Sie Zwischenergebnisse und verwenden Sie einen lokalen Bereitstellungsbereich mit ausreichend Speicherplatz. Bei sehr großen Archiven können Sie die Verarbeitung nach unabhängigen Verzeichnispartitionen parallelisieren, nachdem Sie sichergestellt haben, dass Ausgabereihenfolge und Duplikatbereinigung kontrolliert bleiben.
Voraussetzungen: Lesezugriff auf das XML-Archiv, Schreibzugriff auf den Ausgabeort, Berechtigung zur Ausführung von Python, genehmigter Zugriff auf Zahlungsdaten sowie eine geprüfte Zuordnung der FIS-Kennungen und Statuscodes. Bei dieser dateibasierten Methode werden weder ein bestimmter FIS-Transaktionscode noch ein Menüpfad, API-Endpunkt, Tabellenname oder eine Lizenz vorausgesetzt.

a Beispielabfrage python

from __future__ import annotations

import csv
import hashlib
import re
import sys
import xml.etree.ElementTree as ET
from collections import defaultdict
from datetime import date, datetime, timezone
from decimal import Decimal, InvalidOperation
from pathlib import Path
from typing import Dict, Iterable, List, Optional, Tuple

class=class="hl-string">"hl-comment"># Replace only these documented placeholders.
INPUT_DIRECTORY = Path(class="hl-string">"[Your XML archive directory]")
OUTPUT_FILE = Path(class="hl-string">"[Your ProcessMind event log output path].csv")
START_DATE = class="hl-string">"[YYYY-MM-DD]"
END_DATE = class="hl-string">"[YYYY-MM-DD]"
SOURCE_TIMEZONE = timezone.utc
COMPANY_FILTER = class="hl-string">""  class=class="hl-string">"hl-comment"># Leave empty unless a validated company or business-unit value is required.

class=class="hl-string">"hl-comment"># Update these candidates after inspecting representative FIS XML files.
IDENTIFIER_PATHS = [
    class="hl-string">"EndToEndId", class="hl-string">"TxId", class="hl-string">"InstrId", class="hl-string">"UETR", class="hl-string">"PaymentTransactionId",
    class="hl-string">"PaymentId", class="hl-string">"TransactionId"
]
AMOUNT_PATHS = [class="hl-string">"InstdAmt", class="hl-string">"IntrBkSttlmAmt", class="hl-string">"Amt", class="hl-string">"Amount"]
CURRENCY_PATHS = [class="hl-string">"InstdAmt", class="hl-string">"IntrBkSttlmAmt", class="hl-string">"Amt", class="hl-string">"Currency", class="hl-string">"Ccy"]
DUE_DATE_PATHS = [class="hl-string">"ReqdExctnDt", class="hl-string">"ReqdColltnDt", class="hl-string">"DueDate", class="hl-string">"RequestedExecutionDate"]
SETTLEMENT_DATE_PATHS = [class="hl-string">"SttlmDt", class="hl-string">"SettlementDate", class="hl-string">"ActualSettlementDate"]
TIMESTAMP_PATHS = [
    class="hl-string">"CreDtTm", class="hl-string">"AccptncDtTm", class="hl-string">"AccptncDt", class="hl-string">"OrgnlCreDtTm", class="hl-string">"TxDtTm",
    class="hl-string">"SttlmDt", class="hl-string">"SettlementDate", class="hl-string">"EventTimestamp", class="hl-string">"Timestamp"
]
USER_PATHS = [class="hl-string">"UserId", class="hl-string">"UserID", class="hl-string">"Operator", class="hl-string">"Approver", class="hl-string">"ProcessingUser", class="hl-string">"Initiator"]
PAYMENT_TYPE_PATHS = [class="hl-string">"PmtMtd", class="hl-string">"SvcLvl", class="hl-string">"LclInstrm", class="hl-string">"CtgyPurp", class="hl-string">"PaymentType"]
BUSINESS_UNIT_PATHS = [class="hl-string">"BusinessUnit", class="hl-string">"CompanyCode", class="hl-string">"Company", class="hl-string">"OrgUnit", class="hl-string">"LegalEntity"]
STATUS_PATHS = [class="hl-string">"TxSts", class="hl-string">"GrpSts", class="hl-string">"Status", class="hl-string">"PaymentStatus", class="hl-string">"TransactionStatus"]
REASON_PATHS = [class="hl-string">"Cd", class="hl-string">"Rsn", class="hl-string">"ReasonCode", class="hl-string">"StatusReason", class="hl-string">"AddtlInf"]
ERROR_PATHS = [class="hl-string">"Error", class="hl-string">"Exception", class="hl-string">"Failure", class="hl-string">"ErrorCode", class="hl-string">"ExceptionCode"]
REPAIR_PATHS = [class="hl-string">"Repair", class="hl-string">"Resolved", class="hl-string">"Resolution", class="hl-string">"ErrorResolved", class="hl-string">"ExceptionResolved"]
RECONCILIATION_PATHS = [class="hl-string">"Reconciled", class="hl-string">"ReconciliationStatus", class="hl-string">"LedgerMatched", class="hl-string">"BankStatementMatched"]

class=class="hl-string">"hl-comment"># Validate and extend these mappings against the FIS implementation.
STATUS_ACTIVITY_MAP = {
    class="hl-string">"NEW": class="hl-string">"Payment Request Created",
    class="hl-string">"RECEIVED": class="hl-string">"Payment Request Created",
    class="hl-string">"VALIDATED": class="hl-string">"Payment Details Validated",
    class="hl-string">"PENDING_APPROVAL": class="hl-string">"Payment Sent For Approval",
    class="hl-string">"AWAITING_APPROVAL": class="hl-string">"Payment Sent For Approval",
    class="hl-string">"APPROVAL_PENDING": class="hl-string">"Payment Sent For Approval",
    class="hl-string">"APPROVED": class="hl-string">"Payment Approved",
    class="hl-string">"REJECTED": class="hl-string">"Payment Rejected",
    class="hl-string">"AUTHORIZED": class="hl-string">"Payment Authorized",
    class="hl-string">"SENT": class="hl-string">"Payment Instruction Sent",
    class="hl-string">"DISPATCHED": class="hl-string">"Payment Instruction Sent",
    class="hl-string">"ACCP": class="hl-string">"Payment Confirmed",
    class="hl-string">"ACCEPTED": class="hl-string">"Payment Confirmed",
    class="hl-string">"CONFIRMED": class="hl-string">"Payment Confirmed",
    class="hl-string">"SETTLED": class="hl-string">"Payment Settled",
    class="hl-string">"BOOK": class="hl-string">"Payment Settled",
    class="hl-string">"RECONCILED": class="hl-string">"Payment Reconciled",
}
ERROR_STATUS_CODES = {class="hl-string">"RJCT", class="hl-string">"REJECTED", class="hl-string">"FAILED", class="hl-string">"ERROR", class="hl-string">"EXCEPTION", class="hl-string">"CANCELLED"}
RESOLVED_STATUS_CODES = {class="hl-string">"REPAIRED", class="hl-string">"RESOLVED", class="hl-string">"CORRECTED", class="hl-string">"REPROCESSING", class="hl-string">"REPROCESSED"}

OUTPUT_COLUMNS = [
    class="hl-string">"PaymentTransactionId", class="hl-string">"ActivityName", class="hl-string">"EventTimestamp", class="hl-string">"ProcessingUser",
    class="hl-string">"PaymentAmount", class="hl-string">"CurrencyCode", class="hl-string">"PaymentType", class="hl-string">"PaymentDueDate",
    class="hl-string">"ActualSettlementDate", class="hl-string">"BusinessUnit"
]


def local_name(tag: str) -> str:
    return tag.rsplit(class="hl-string">"}", 1)[-1].lower()


def text_values(root: ET.Element, candidates: Iterable[str]) -> List[str]:
    wanted = {candidate.lower() for candidate in candidates}
    values: List[str] = []
    for element in root.iter():
        if local_name(element.tag) in wanted:
            value = (element.text or class="hl-string">"").strip()
            if value:
                values.append(value)
            for key, attribute_value in element.attrib.items():
                if key.rsplit(class="hl-string">"}", 1)[-1].lower() in {class="hl-string">"ccy", class="hl-string">"currency"} and attribute_value.strip():
                    values.append(attribute_value.strip())
    return values


def first_value(root: ET.Element, candidates: Iterable[str]) -> str:
    values = text_values(root, candidates)
    return values[0] if values else class="hl-string">""


def normalize_code(value: str) -> str:
    return re.sub(rclass="hl-string">"[^A-Z0-9_]", class="hl-string">"", value.upper().replace(class="hl-string">"-", class="hl-string">"_"))


def parse_datetime(value: str) -> Optional[datetime]:
    if not value:
        return None
    candidate = value.strip()
    if candidate.endswith(class="hl-string">"Z"):
        candidate = candidate[:-1] + class="hl-string">"+00:00"
    try:
        parsed = datetime.fromisoformat(candidate)
    except ValueError:
        for fmt in (class="hl-string">"%Y-%m-%d %H:%M:%S", class="hl-string">"%Y-%m-%d", class="hl-string">"%Y%m%d%H%M%S", class="hl-string">"%Y%m%d"):
            try:
                parsed = datetime.strptime(value.strip(), fmt)
                break
            except ValueError:
                parsed = None
        if parsed is None:
            return None
    if parsed.tzinfo is None:
        parsed = parsed.replace(tzinfo=SOURCE_TIMEZONE)
    return parsed.astimezone(timezone.utc)


def output_timestamp(value: Optional[datetime]) -> str:
    return value.astimezone(timezone.utc).isoformat().replace(class="hl-string">"+00:00", class="hl-string">"Z") if value else class="hl-string">""


def output_date(value: str) -> str:
    parsed = parse_datetime(value)
    return parsed.date().isoformat() if parsed else (value[:10] if re.match(rclass="hl-string">"^\d{4}-\d{2}-\d{2}", value) else class="hl-string">"")


def normalize_amount(value: str) -> str:
    if not value:
        return class="hl-string">""
    try:
        return format(Decimal(value.replace(class="hl-string">",", class="hl-string">"").strip()), class="hl-string">"f")
    except InvalidOperation:
        return value.strip()


def source_message_id(path: Path, root: ET.Element) -> str:
    raw = path.as_posix() + class="hl-string">"|" + first_value(root, [class="hl-string">"MsgId", class="hl-string">"MessageId", class="hl-string">"BizMsgIdr"])
    return hashlib.sha256(raw.encode(class="hl-string">"utf-8")).hexdigest()


def in_date_range(event_time: Optional[datetime]) -> bool:
    if not event_time:
        return True
    start = datetime.fromisoformat(START_DATE).replace(tzinfo=timezone.utc)
    end = datetime.fromisoformat(END_DATE).replace(tzinfo=timezone.utc)
    return start <= event_time < end.replace(hour=23, minute=59, second=59, microsecond=999999)


def add_event(events: List[Dict[str, str]], seen: set, transaction_id: str, activity: str,
              event_time: Optional[datetime], user: str, amount: str, currency: str,
              payment_type: str, due_date: str, settlement_date: str, business_unit: str,
              message_id: str) -> None:
    if not transaction_id or not event_time or not in_date_range(event_time):
        return
    row = {
        class="hl-string">"PaymentTransactionId": transaction_id,
        class="hl-string">"ActivityName": activity,
        class="hl-string">"EventTimestamp": output_timestamp(event_time),
        class="hl-string">"ProcessingUser": user,
        class="hl-string">"PaymentAmount": amount,
        class="hl-string">"CurrencyCode": currency,
        class="hl-string">"PaymentType": payment_type,
        class="hl-string">"PaymentDueDate": output_date(due_date),
        class="hl-string">"ActualSettlementDate": output_date(settlement_date),
        class="hl-string">"BusinessUnit": business_unit,
    }
    key = (transaction_id, activity, row[class="hl-string">"EventTimestamp"], message_id)
    if key not in seen:
        seen.add(key)
        events.append(row)


def parse_file(path: Path, events: List[Dict[str, str]], seen: set) -> None:
    try:
        root = ET.parse(path).getroot()
    except (ET.ParseError, OSError) as exc:
        print(fclass="hl-string">"Could not parse {path}: {exc}", file=sys.stderr)
        return
    message_id = source_message_id(path, root)
    transaction_id = first_value(root, IDENTIFIER_PATHS)
    if not transaction_id:
        return
    business_unit = first_value(root, BUSINESS_UNIT_PATHS)
    if COMPANY_FILTER and business_unit != COMPANY_FILTER:
        return
    amount = normalize_amount(first_value(root, AMOUNT_PATHS))
    currency = first_value(root, CURRENCY_PATHS)
    if len(currency) != 3 and currency:
        currency = currency.upper()
    due_date = first_value(root, DUE_DATE_PATHS)
    settlement_date = first_value(root, SETTLEMENT_DATE_PATHS)
    user = first_value(root, USER_PATHS)
    payment_type = first_value(root, PAYMENT_TYPE_PATHS)
    status_values = text_values(root, STATUS_PATHS)
    reason_values = text_values(root, REASON_PATHS)
    error_values = text_values(root, ERROR_PATHS)
    repair_values = text_values(root, REPAIR_PATHS)
    reconciliation_values = text_values(root, RECONCILIATION_PATHS)
    event_time = parse_datetime(first_value(root, TIMESTAMP_PATHS))
    if not event_time:
        return

    message_name = next((local_name(element.tag) for element in root.iter() if local_name(element.tag) in {class="hl-string">"pacs.008", class="hl-string">"pacs.002", class="hl-string">"document"}), class="hl-string">"")
    normalized_statuses = [normalize_code(value) for value in status_values + reason_values]
    normalized_text = class="hl-string">" ".join(normalize_code(value) for value in error_values)
    normalized_repairs = class="hl-string">" ".join(normalize_code(value) for value in repair_values)
    normalized_reconciliation = class="hl-string">" ".join(normalize_code(value) for value in reconciliation_values)

    if message_name or status_values:
        add_event(events, seen, transaction_id, class="hl-string">"Payment Request Created", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"NEW", class="hl-string">"RECEIVED"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Details Validated", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if class="hl-string">"VALIDATED" in normalized_statuses else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Sent For Approval", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"PENDING_APPROVAL", class="hl-string">"AWAITING_APPROVAL", class="hl-string">"APPROVAL_PENDING"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Approved", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if class="hl-string">"APPROVED" in normalized_statuses else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Rejected", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"REJECTED", class="hl-string">"RJCT"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Authorized", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if class="hl-string">"AUTHORIZED" in normalized_statuses else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Instruction Sent", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"SENT", class="hl-string">"DISPATCHED"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Confirmed", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"ACCP", class="hl-string">"ACCEPTED", class="hl-string">"CONFIRMED"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Settled", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if any(code in {class="hl-string">"SETTLED", class="hl-string">"BOOK"} for code in normalized_statuses) else None
        add_event(events, seen, transaction_id, class="hl-string">"Payment Reconciled", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id) if class="hl-string">"RECONCILED" in normalized_statuses or any(code in normalized_reconciliation for code in {class="hl-string">"TRUE", class="hl-string">"MATCHED", class="hl-string">"RECONCILED"}) else None

    if any(code in ERROR_STATUS_CODES for code in normalized_statuses) or normalized_text:
        add_event(events, seen, transaction_id, class="hl-string">"Payment Error Identified", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id)
    if any(code in RESOLVED_STATUS_CODES for code in normalized_statuses) or any(code in normalized_repairs for code in {class="hl-string">"TRUE", class="hl-string">"RESOLVED", class="hl-string">"REPAIRED", class="hl-string">"CORRECTED"}):
        add_event(events, seen, transaction_id, class="hl-string">"Payment Error Resolved", event_time, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id)

    due = parse_datetime(due_date)
    settled = parse_datetime(settlement_date)
    if due and settled and settled.date() > due.date():
        add_event(events, seen, transaction_id, class="hl-string">"Late Payment Identified", settled, user, amount, currency, payment_type, due_date, settlement_date, business_unit, message_id)


def main() -> None:
    events: List[Dict[str, str]] = []
    seen = set()
    for path in sorted(INPUT_DIRECTORY.rglob(class="hl-string">"*.xml")):
        parse_file(path, events, seen)
    events.sort(key=lambda row: (row[class="hl-string">"PaymentTransactionId"], row[class="hl-string">"EventTimestamp"], row[class="hl-string">"ActivityName"]))
    OUTPUT_FILE.parent.mkdir(parents=True, exist_ok=True)
    with OUTPUT_FILE.open(class="hl-string">"w", newline=class="hl-string">"", encoding=class="hl-string">"utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=OUTPUT_COLUMNS)
        writer.writeheader()
        writer.writerows(events)
    print(fclass="hl-string">"Wrote {len(events)} event rows to {OUTPUT_FILE}")


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

Möchten Sie loslegen?

Verwenden Sie dieses Template, um die Datenerfassung zu vereinfachen und Verbesserungen in der Zahlungsabwicklung anzustoßen. Ermitteln Sie Effizienzpotenziale und stärken Sie die Finanzkontrolle mit präzisen Erkenntnissen zu Ihren Prozessen.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Optimieren Sie noch heute Ihre Zahlungsabwicklung mit FIS Global

Erreichen Sie eine Straight-Through-Processing-Quote von 98 % und vermeiden Sie Abstimmungsprobleme.

Starten Sie jetzt Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. In wenigen Minuten startklar.

Ihr Daten-Template für die Zahlungsabwicklung

Ihr Daten-Template für die Zahlungsabwicklung

Attribute der Zahlungsabwicklung

Aktivitäten der Zahlungsabwicklung

Anleitungen zur Datenextraktion

ISO-20022-XML-Protokolldateien mit Python auswerten

Schritte

Konfiguration

a Beispielabfrage python

Möchten Sie loslegen?

Optimieren Sie noch heute Ihre Zahlungsabwicklung mit FIS Global

Der Schutz Ihrer Daten ist uns wichtig