SAP Payment Engine

Clearingkreis

Der Clearing-Kreis ist eine Organisationseinheit innerhalb von Zahlungsvorgängen. Die meisten Geschäftsobjekte und betriebswirtschaftlichen Regeln, die in der Zahlungsverarbeitung verwendet werden, sind nach Clearingkreisebenen aufgeteilt. Clearingkreise dienen als Unterstruktur unterhalb der Mandantenebene.

File Handler

Der File Handler akzeptiert Dateien von Vorsystemen, bestimmt das Format und transferiert die Daten zum entsprechenden Formatkonverter.

Am Ende der Auftragsverarbeitung übergibt der File Handler die prozessierten Zahlungsdaten zum Weiterleitungssystem im entsprechenden Format.

Der File Handler (FH) besteht aus zwei Teilen: Dateien-Interface und Format-Konverter. Die Schnittstelle akzeptiert die Dateien vom Vorsystem, bestimmt den Format-Konverter und übergibt die Dateien an diesen.

• Der Input Manager (IPM) ist das Upload-Interface des File Handlers: Er erhält Zahlungsdaten, wie z.B. Zahlungsaufträge und Zahlungsposten, und konvertiert sie in das PE-interne Meta-Format.
• Der Output Manager (OPM) ist File Handlers Download-Interface: Er transferiert verarbeitete Zahlungsdaten nach außen in die entsprechenden externen Zielformate zu den Weiterleitungssystemen, und fügt Daten von der FHDB je nach Notwendigkeit hinzu.
• Die File Handler Database (FH DB) wird von den individuellen Konvertern der PE verwendet, um Informationen, die nicht in den Attributen der PE Geschäftsobjekte zugeordnet sind, zu speichern.

Enrichment & Validation

Dieser Prozess ermöglicht anhand verschiedener Prüfungen, die zu Beginn der Zahlungs-verarbeitung durchgeführt werden, die Validierung der Attribute von Zahlungsaufträgen und -posten in der Payment Engine.

• Anreicherung: Zahlungsaufträgen und -posten werden anhand der Customizing-Einstellungen für die verschiedenen Prüfungen und der ermittelten Service-Level-Agreements (SLA) Informationen hinzugefügt.
• Validierung: Prüfung der Richtigkeit der Informationen.

Wenn Informationen fehlen oder fehlerhaft sind, kann die PE eine interne automatische Reparaturfunktion verwenden, um eine Korrektur vorzunehmen, oder Informationen können manuell korrigiert werden.

Dies hängt von den Einstellungen ab, die für die Ausnahmesteuerung definiert wurden.

Routing Control

Dieser Prozess steuert die Verarbeitung der Aufträge und Zahlungsposten zu den konfigurierten Zielsystemen. Eine Vielzahl von Einstellung ermöglicht eine feine Steuerung.

Leitweg -Entscheidung über interne oder externe Verarbeitung

Clearingvereinbarung -Zusätzliche Gruppierung innerhalb eines Leitwegs

• Ein Clearing Agreement (CA) beinhaltet alle Informationen, die für die weitere Verarbeitung eines Zahlungspostens notwendig sind.
• CAs gehören zu einer Route und können wie diese intern oder extern sein.

1. 1.  in einer internen Route gibt es nur interene CAs.
   2.  in einer externen Route gibt es nur externe CAs.

Exception Handling 

Exception Handling behandelt alle Situationen in der Zahlungsauftrags- und Zahlungspostenverarbeitung, die von einem STP abweichen

• Aussteuerung von Fehlern während der STP-Verarbeitung
• Regeln, die es erlauben Reaktionsarten für Fehlersituation zu definieren, die während der Prozessierung auftreten
• Die bevorzugten Reaktionen bei einer bestimmten Fehlersituation wird durch Rückmeldungsarten, die detailiert in der Fehlerbehandlung definiert werden können, ausgeführt

Proxy

Proxy erlaubt mehrere Funktionen:

• Interaktion mit den Account Management Systemen: Innerhalb des Clearing-Prozesses, und basierend auf der Konfiguration, führt der AM Proxy mehrere Funktionen für alle Zahlungspostenarten durch:
  • Buchungssimulation
  • Buchung
  • Reservierung (Prenote)
  • Reservierungslöschung (Prenote löschen)
  • Return
• Zuordnung von Daten: AM-Proxy ist verantwortlich für die Zuordnung von zahlungsrelevanten Informationen zu der Struktur eines relevanten Kontoführungssystems (AMS), um bestimmte Aktionen auf Kontolevel durchzuführen.
• Interpretation und Behandlung von AMS Rückmeldungen: AM Proxy sendet Anfragen an das AMS, erhält von ihm Antworten und reagiert dementsprechend darauf (z.B. Exception Handling).

Proxy bietet mehrere technische Funktionen um die Leistung und Robustheit des Systems sicher zu stellen:

• Single-Prozessierung vs. Packaging: Zusätzlich zur Single-Prozessierung eines Zahlungspostens ermöglicht die Packetierung von Posten die Payment Engine den AM Proxy in mehreren parallelen Prozessen aufzurufen, was die Systemleistung signifikant erhöht.
• Synchrone vs. Asynchrone Prozessierung: Die synchrone Verarbeitung von Posten wird durch eine offene RFC-Verbindung  zu einem AMS bereit gestellt. Die asynchrone Verarbeitung von Posten wird bspw. genutzt wenn eine Verbindung vorrübergehend nicht verfügbar ist.
• Notfallszenarios: Der AM Proxy ist in der Lage Notfallszenarios zu behandeln, wie z.B.

Behandlung von Timeouts während einer Buchungssimulation, Reservierung und Buchungsanfrage

Buchungen von Zahlungsposten zu erzwingen um mit der Verarbeitung fortzusetzen, selbst wenn die Verbindung zum AMS nicht vorhanden ist

Massenwiedervorlage von Zahlungsposten

Behandlung eines Restarts nach einem Absturz der Payment Engine

End of day – Verarbeitung 

Die EoD-Verarbeitung schließt an einem bestimmten Geschäftstag der Bank gemäß der korrekten organisatorischen und buchhalterischen Praktiken die Verarbeitung ab. Der Prozess stellt sicher, dass ein Buchungstag synchron mit den angebundenen Kontoführungssystemen korrekt abgeschlossen wird, sodass die Abstimmung stattfinden kann.

• Die EoD-Prozesse müssen mit den anderen EoD Aktivitäten umliegender Anwendungen synchronisiert sein, um die Gesamtintegrität und die korrekte Prozessierung aller Zahlunagsaufträge eines Geschäftstages sicher zu stellen.
• Fehler in der Tagesverarbeitung können im Rahmen des EoD-Prozesses am Tagesende entdeckt werden, und für eine Fehlereliminierung sorgen.
• Der EoDP wird für jeden Clearingkreis durchgeführt – nicht für jedes angeschlossene Kontoführungssystem!

Prozessablauf

• Erhöhung des Abstimmdatums: Das System setzt das Abstimmdatum auf den nächsten Geschäftstag.
• Verarbeitung aller Zahlungsaufträge, die keinen finalen Status mit einem Abstimmdatum besitzen, das entweder dem aktuellen Datum entspricht oder davor liegt (früher als der Zeitpunkt, an dem die Tagesendverarbeitung initiiert wurde).
• Schließung offener Sammler und Queues, für die das Ende des Tages als Schließkriterium definiert ist, und Initiierung der Endverarbeitung dieser Sammler und Queues. (Schließkriterien für Sammler und Queues werden in der Clearingvereinbarung definiert).
• Erzeugung der Abstimmauswertungsreports.
• Erzeugung eines Reports über Unstimmigkeiten zwischen Payment Engine und einem Kontoführungssystem.

Anwendungssteuerung per FIORI Oberfläche