Diese Transaktion verarbeitet eingehende Nachrichten in unterschiedlichen Formaten. Eine Datei kann eine oder mehrere Nachrichten im entsprechenden Format enthalten.

Die Verarbeitung von Teilnachrichten, wie beispielsweise bei SWIFT MT 700 und MT 701, wird unterstützt, d.h. einzelne, zusammengehörige Teilnachrichten werden als eine gesamte Nachricht betrachtet und für die weitere Bearbeitung zur Verfügung gestellt.

Die Applikation unterstützt zur Zeit folgende Nachrichtenformate (siehe Tabelle im folgenden Abschnitt) in der Eingangsverarbeitung.

Andere Nachrichtenschnittstellen können in Übereinstimmung mit den Anforderungen der Bank definiert werden.

Die Nachrichten werden als Textdateien üblicherweise in Unterverzeichnissen der Partition “Data” gespeichert.

Relative Pfadnamen für die Angabe der Eingangsverzeichnisse sind daher relativ zur Partition “Data”. Wenn es aus organisatorischen Gründen notwendig ist, können allerdings auch absolute Pfadnamen angegeben werden. Dabei ist außerdem die Verwendung des Präfixes “db:” (Dateien in Datenbanken) möglich. Wahlweise können die Eingangsnachrichten in separaten Verzeichnissen je Entity oder in einem gemeinsamen Verzeichnis für die gesamte Installation abgegeben werden.

Die Transaktion führt die folgenden Schritte durch:

1. Lesen einer Nachricht von einem der angegebenen Verzeichnisse.
2. Abhängig vom Unterverzeichnis entscheiden, um welches Nachrichtenformat es sich handelt.
3. Falls die Datei mehrere Blöcke von Nachrichten mit jeweils eigenem Header und Footer enthält, was z.B. bei DTA-, DTE- und DTG-Nachrichten vorkommen kann, werden aus der Datei physikalisch mehrere Teildateien mit jeweils einem Nachrichtenblock erstellt, die den Namen der Originaldatei und einer Laufnummer (vor der Dateierweiterung) erhalten . Die Originaldatei wird nach dem Erstellen der Teildateien in das Archiv-Verzeichnis arc verschoben.
4. Splitten einer Datei, die mehrere Nachrichten enthält, in jeweils eine Nachricht. Bei Dateiformaten mit Header-Blöcken werden diese Daten jeder Einzelnachricht vorangestellt, d.h. eine physikalische Eingangsdatei kann mehrere Absender haben. Der Absender steht in einem der A-Tags. Eine physikalische Datei wird in so viele einzelne physikalische Dateien aufgeteilt, wie es unterschiedliche Absender gibt.
5. Teilt jede Nachricht in einzelne Felder gemäß den Syntaxregeln wie beschrieben in der jeweiligen TAG-Datei. Die TAG-Datei ist in der Partition “Ini” gespeichert.
6. Kombiniert Nachrichten, die in mehrere Nachrichten aufgeteilt wurden (z.B. 700 und 701), gemäß der SWIFT-Längenbegrenzung in eine einzelne Nachricht, sobald die letzte Nachricht einer Sequenz gefunden wurde (unabhängig von der Eingangssequenz). Wenn eine SCORE-Nachricht das Tag 23X mit Kanal 'FACT' (FileAct) enthält , wird die Kombination von Nachrichten erst dann durchgeführt, wenn sowohl alle Teilnachrichten als auch die Datei, auf die in Tag 23X verwiesen wird, eingegangen sind.
7. Die Nichteinhaltung der Vorgaben kann dazu führen, dass überlange SWIFT-Nachrichten am Ende abgeschnitten werden. Diese abgeschnittenen Nachrichten werden von der Applikation an den Kunden weitergeleitet, wobei gleichzeitig eine Warnung vom System ausgegeben wird, dass die Akkreditivdaten unvollständig sind.
8. Sollte auch der Block, der die nicht zugeordneten Felder enthält, zu klein sein (max. 65 Zeichen a 100 Zeilen), wird der Inhalt für das jeweilige Tag aus “Unmapped” entfernt und stattdessen eine Fehlermeldung in “Unmapped” geschrieben, dass die Eingangsnachricht geprüft werden muss.
9. Entscheidet über die auszuführende Transaktion für diese Nachricht gemäß den Regeln, wie sie in Regel “SRVSWI.DetermineMT” aufgestellt sind. Beispiel: Die Entscheidung, welche Transaktion letztendlich dem Eingang zugeordnet wird, wird in der Software im Modul SRVSWI in der Regel “DetermineMT()” getroffen. Im einfachsten Fall ist dies eine Ableitung aus dem Nachrichtentyp. Sollte aus dem Nachrichtentyp nicht eindeutig hervorgehen, welche Transaktion damit zu verknüpfen ist, können Tags der Nachricht zur weiteren Analyse / Identifizierung verwendet werden.
   Hantieren fehlerhafter Referenznummern: Die eigene Referenznummer (OWNREF) darf NIE als Ziel der Zuordnung verwendet werden. Wird eine eigene Referenznummer in SWM gefunden, die nicht ignoriert werden soll und die ungleich der aktuellen Referenz ist, wird diese im Feld “unmapped” gespeichert und ein Fehlertext ausgeben.
10. Abbilden der Datenfelder in Transaktionsfeldern wie in “Verwalten von Feldzuordnungen für Eingangsnachrichten” definiert.
11. Bei zu langen Dateinamen wird die Datei in eine mit maximal 28 Zeichen langem Dateinamen, der einen Timestamp enthält, kopiert.
12. Erzeugt einen “strukturierten Nachrichtenkopf” Eintrag für die Nachricht (SMH-Satz).
13. Wenn genau angegeben, Druck einer formatierten und/oder einer unverarbeiteten Kopie der Nachricht auf dem genau angegebenen Drucker.
14. Erzeugt einen Eintrag in die Liste der offenen Vorgänge.
15. Wenn kein Fehler aufgetreten ist, Verschieben der Datei in das Unterverzeichnis “arc” (z.B. “swtin/arc”) der Partition, anderenfalls in das Unterverzeichnis “error” der Partition.
    Hinweis: Eine Datei kann mehr als eine Nachricht enthalten. Wenn bei der inhaltlichen Verarbeitung einer Nachricht in dieser Datei ein Fehler auftritt, aber ggf. schon andere Nachrichten in dieser Datei korrekt verarbeitet werden konnten, wird die Datei sowohl nach “arc” (für die Archivierung der erfolgreich verarbeiteten Nachricht) als auch nach “error” (für eine nicht erfolgreich verarbeitete Nachricht) verschoben bzw. kopiert.

Unter Benutzung der Schalter “-I <Name der ini-Datei>” in der Kommandozeile des Verarbeitungssystems können verschiedene Instanzen dieser Transaktion gestartet werden (z.B. eine, wonach SWIFT von 08.00h bis 18.00h alle 10 Minuten läuft und eine andere Instanz für TradeConnect-Nachrichten, die nur einmal täglich gestartet wird).

Für den Nachrichtentyp SWIFT XML (z.B. ISO20022 CBPR+ XML Zahlungsnachrichten) wurde der neue Dienst SRVSXI eingeführt. Dieser Dienst wird für den Import eingehender Nachrichten, z.B.Pacs.008, Pacs.009 und technischer Ack/Nack-Übertragungsnachrichten verwendet (Sie sind das Ergebnis einer technischen auf strukturelle Konformität gemäß dem Swift MX Regelwerk). Beispiele: Eingehende Pacs.008-Nachrichten werden an die Transaktion CPTSET (ähnlich wie eingehende MT103) und eingehende Pacs.009-Nachrichten an die Transaktion SPTROU (ähnlich wie MT202) weitergeleitet. Die technische Ack/Nack-Bestätigungsnachricht wird nicht auf einen Vertrag abgebildet, sondern nur empfangen, um den Ack/Nack-Status des Vertrags zu registrieren.

Für ein ordnungsgemäßes Funktionieren der Eingangsverarbeitung ist es erforderlich, dass in SWITSK.INI eine Default-Entity eingetragen wird. Diese Default-Entity wird genommen, wenn keine andere Entity dem Benutzer zugewiesen wurde. Der Zugriff erfolgt folgendermaßen:

Wenn die Nachricht einem Kontrakt zugeordnet werden kann, wird die Entity des Kontraktes verwendet.

Ist kein Kontrakt vorhanden, wird:

• Bei SWIFT-Nachrichten der Empfänger-BIC zur Identifizierung der Entity verwendet. Der BIC aus II_BIC wird zuerst in einen 11-stelligen BIC umgewandelt, falls er 12-stellig ist. Anschließend wird eine Adresse mit diesem BIC gesucht, die als “Eigene Adresse” (Own) bei einer Entity eingetragen ist. Gibt es mehrere Adressen mit diesem BIC, wird die als “Primäradresse” markierte benutzt. Aus der gefundenen Adresse wird die Entity verwendet.

• Für DTA-/DTE-/DTG- und TradeConnect-Nachrichten wird die DTA/DTE/DTG-ID bzw. die TID der Empfänger-Entity aus dem Inhalt von Tag “A2” der Nachricht bestimmt. Wenn dieses Feld nur aus Ziffern besteht, wird der Inhalt als Bankleitzahl, sonst als BIC interpretiert und anschließend eine Adresse mit dieser BLZ bzw. BIC bzw. TID gesucht, die als “Eigene Adresse” (Own) bei einer Entity eingetragen ist. Gibt es mehrere Adressen mit diesem Schlüssel, wird die als “Primäradresse” markierte benutzt. Aus der gefundenen Adresse wird die Entity verwendet.

Wenn auf diesem Wege keine Entity identifiziert wurde, wird die in SWITSK.INI in Abschnitt [Settings] unter “DefaultETY=” eingetragene Default-Entity verwendet.

Diese Logik zur Entity-Zuordnung kann in der Regel “SWITSK.DetermineETY” projektspezifisch angepasst werden.

Wenn ein Kontrakt vorhanden ist, wird die Benutzergruppe des für den Kontrakt verantwortlichen Benutzers als Benutzergruppe verwendet. In allen anderen Fällen wird die Default-Benutzergruppe der ausgewählten Entity als Benutzergruppe verwendet.

In SCORE Nachrichten kann in Tag 23X angegeben werden, dass zu dieser Nachricht (die selbst aus mehreren Teilnachrichten bestehen kann) eine weitere Datei (logisch ist das ein Anhang zur Nachricht) in beliebigem Format gehört, die außerhalb des SWIFT FIN Services transportiert wird. Wenn der im Tag 23X angegebene Transportweg (delivery channel) SWIFT FileAct ist, werden die Teile der SCORE-Nachricht und der Anhang von der Anwendung zusammengeführt. Die Nachricht erscheint erst dann im Eingangskorb, wenn die letzte Teilnachricht und gegebenenfalls der Anhang eingegangen sind.

Technische Vorgehensweise:

Wenn die SCORE Nachrichten vollständig vorhanden sind, wird beim Zusammenfügen der Teilnachrichten geprüft, ob schon ein SMX-Satz vorhanden ist, in dem Absender, Empfänger und Dateiname zu den Angaben des Tags 23X passen.

• Wenn nein, wird ein solcher SMX-Satz (ohne SMH-Satz) mit einem Verweis auf die zugehörige SCORE Nachricht angelegt, damit SRVSFI die Nachrichten zusammenfügen kann, sobald der Anhang eingeht.
• Wenn ja, wird in den SMX-Satz der zusätzliche Verweis eingetragen, der den Anhang identifizierende SMH-Satz dem der ersten SCORE-Nachricht untergeordnet und der Eintrag im Eingangskorb (SPT) erstellt.

Über FILEACT eingehende Nachrichten werden vom Service SRVSFI verarbeitet. Für jede eingehende Datei wird ein SMH-Satz mit CORTYP 'FIL' und Message Type 'FILEACT' erzeugt. Außerdem wird geprüft, ob schon ein SMX-Satz vorhanden ist, in dem Absender, Empfänger und Dateiname zur eingegangenen Datei passen.

• Wenn nein, wird ein solcher SMX-Satz (ohne SMH-Satz) angelegt, damit SRVSFI die Nachrichten zusammenfügen kann, sobald der Anhang eingeht.
• Wenn ja, wird dieser SMX-Satz verwendet. Wenn in dem SMX-Satz der zusätzliche Verweis auf eine dazugehörende SCORE-Nachricht mit Tag 23X (erstellt von SRVSWI) gefunden wird, wird der SMH-Satz des Anhangs dem so identifizierten SMH-Satz der ersten SCORE-Nachricht untergeordnet, die Teile der SCORE-Nachricht zusammengeführt und verarbeitet und der Eintrag im Eingangskorb (SPT) erstellt.

Die Triggerformate “Swift Alliance Access XML v2 as Trigger” und “Swift Alliance Access XML v2 PDU via MQ” unterstützen den Empfang von FILEACT-Anhängen via XMLv2-Nachrichten.

Swift Alliance Access XML v2 as Trigger

• Im definierten Eingangsverzeichnis werden 2 Dateien erwartet. Die XMLv2 (oder data pdu) ist der Trigger für die Verarbeitung. Im <body>-Element wird der physische Name der Anhangsdatei erwartet. Ist die Datei nicht vorhanden, wird die Eingangsnachricht ins Error-Verzeichnis verschoben und übersprungen. Ist die Datei vorhanden, werden beide Dateien ins Archiv-Verzeichnis verschoben. Dabei wird die Anhangsdatei ggf. gemäß <LogicalFileName> umbenannt.

Swift Alliance Access XML v2 via MQ

• Bei diesem Trigger werden data PDU - Dateien von MQ abgeholt. Die XMLv2-Datei und die Anhangsdatei werden aus den data PDU - Dateien extrahiert. Die weitere Verarbeitung erfolgt dann wie beim “Swift Alliance Access XML v2 as Trigger”

Eingehende E-Mail-Nachrichten, die eine Signatur enthalten, für die aber kein Zertifikat bzw. public key gespeichert ist, können ohne Fehler importiert werden.

Dazu muss im File “emlmod.ini” in der Section [System] der Eintrag IGNSIGFLG=“Y” gesetzt werden.

Bei gesetztem Flag werden Fehler beim Prüfen der Signature in multipart/signed - Elementen ignoriert - das negative Prüfungsergebnis wird nur im extrahierten raw-Text vermerkt.

Bei einigen eingehenden Nachrichtentypen ist es möglich eine Benachrichtigungs E-Mail für einen speziellen Empfänger zu versenden. Die Mail enthält einen Link, so dass die korrekte Transaktion für diese Eingangsnachricht sofort gestartet wird.

Falls 'Sende E-Mail' eingeschaltet ist, wird eine Benachrichtigungs E-Mail generiert.
Die Versandart kann sein:

• Kundenspezifisch ( Dabei ist eine kundenspezifische Programmierung notwendig )
• Pickup-Verzeichnis ( Die E-Mail wird in einem Verzeichnis abgelegt. Die Datei wird von einer Software ausserhalb von DNG verarbeitet )
• SMTP ( Sende E-Mail über SMTP )
• Unix sendmail( Sende E-Mail mit Unix sendmail )

Im Pickup Verzeichnis werden die E-Mails erzeugt.

In dem SMTP Block müssen die SMTP Settings spezifiziert werden.

Für Windows Systeme muss Konvertiere Zeilenende zu 0D0A normalerweise eingeschaltet werden.

Das Kommando muss eine URL zu einem DNG HTML5 Client mit Rechner und Port sein.

Felder für die E-Mail:

• Von E-Mail
• Default Empfänger E-Mail
• Subject
• Text E-Mail Text

Der E-Mail Text sollte das Tag <URL> enthalten. Dieses Tag wird durch das Kommando, ergänzt um eine SPT.INR und einen Transaktionsnamen, ersetzt. Wenn der Empfänger auf diesen Link klickt, wird der HTML5 Client gestartet. Nach dem Login startet DNG sofort die Transaktion für die eingegangene Nachricht.

SWITSK verfügt über eine Möglichkeit, E-Mails aus der Remote Mailbox über die Standard-POP3/IMAP-Schnittstelle abzuholen.
Derzeit ist diese Funktion für die Nachrichtentypen SmartForms und EasySend verfügbar. Um sie zu aktivieren muss die Checkbox “Briefkasten” angekreuzt werden. Wenn diese aktiviert ist - wird die Mailbox bei der regelmäßigen Aktualisierung von SWITSK auf neue E-Mails geprüft.

Die Verbindungseinstellungen sind über den Button “Einstellungen” konfigurierbar. Einmal angeklickt - erscheint das folgende Pop-up mit der Standard-Mail-Client-Konfiguration:

Im Vordergrund laufende Manager-Prozesse sind grundsätzlich manuell zu starten.

Die nachfolgenden Erläuterungen gelten für alle Konfigurations-Panels für die Nachrichtenformate gleichermaßen.

Manager für eingehende Nachrichten
SWIFT eingehend
TCO eingehend
Telex
DTA Import L/C
DTA Export L/C
DTA Garantien
E-mail
Bolero
Swift FileAct + XMLv2
allNETT
allNETT STT
SmartForms
EasySend
Finanz. Dokumente eingehend
SWIFT XML
RIVO
RIVO STT

Dies ist das Hauptfenster, in dem alle “Eingehenden Nachrichten” angezeigt werden, die in den jeweiligen Zielverzeichnissen verfügbar sind. Dem Benutzer stehen Auswahlkriterien zur Verfügung, um die gewünschten Dienst-/Nachrichtentypen auszuwählen, die aufgelistet werden sollen, und die eingehenden Nachrichten werden für diese ausgewählten Diensttypen angezeigt.

Dies ist das Konfigurations-Panel für eingehende SWIFT- und SCORE-Nachrichten. Es besteht die Möglichkeit, die Zielverzeichnisse für eingehende SWIFT- und SCORE-Nachrichten sowie die erforderliche Dateierweiterung für diese Nachrichtendateien anzugeben. Darüber hinaus kann der Benutzer auch die Druckeinstellungen konfigurieren und den lokalen Authentifizierungs-Hash aktivieren, indem er seine Schlüsseldaten angibt.

Dieses Konfigurations-Panel ist für TradeConnect-Nachrichten für TCWEB. Die Option ist verfügbar, um die eingehenden Zielverzeichnisse für TradeConnect-Nachrichten anzugeben, zusammen mit der erforderlichen Datei-Erweiterung für diese Nachrichtentypen. Die Datenstruktur wird mit DTA für LC-Nachrichten und DTG für Garantie-Nachrichten zusammengeführt. Darüber hinaus kann der Benutzer auch die Druckeinrichtung konfigurieren und den lokalen Authentifizierungs-Hash aktivieren, indem er seine Schlüsseldaten angibt.

Dieses Konfigurations-Panel ist für eingehende Telex-Nachrichten vorgesehen (elektronische Kommunikationsnachrichten, die vor SWIFT weit verbreitet waren). Es besteht die Möglichkeit, die Zielverzeichnisse für eingehende Telex-Nachrichten sowie die erforderliche Datei-Erweiterung für diese Nachrichtentypen anzugeben. Außerdem kann der Benutzer die Druckereinrichtung konfigurieren.

Dies ist das Konfigurations-Panel für eingehende DTA-Nachrichten für Import LC. Es besteht die Möglichkeit, die Zielverzeichnisse für eingehende DTA-Import-LC-Nachrichten sowie die erforderliche Datei-Erweiterung für diese Nachrichtendateien anzugeben. Darüber hinaus kann der Benutzer auch die Druckeinstellungen konfigurieren und den lokalen Authentifizierungs-Hash aktivieren, indem er seine Schlüsseldaten angibt.

Dies ist das Konfigurations-Panel für eingehende DTA-Nachrichten für Export LC. Die Option ist verfügbar, um die Zielverzeichnisse für eingehende DTA-Export-LC-Nachrichten sowie die erforderliche Datei-Erweiterung für diese Nachrichtentypen anzugeben. Darüber hinaus kann der Benutzer auch die Druckeinstellungen konfigurieren und den lokalen Authentifizierungs-Hash aktivieren, indem er seine Schlüsseldaten angibt.

Dies ist das Konfigurations-Panel für eingehende DTA (DTG)-Nachrichten für Garantienachrichten. Es besteht die Möglichkeit, die Zielverzeichnisse für eingehende DTA-Garantienachrichten sowie die erforderliche Datei-Erweiterung für diese Nachrichtentypen anzugeben. Darüber hinaus kann der Benutzer auch die Druckeinstellungen konfigurieren und den lokalen Authentifizierungs-Hash aktivieren, indem er seine Schlüsseldaten angibt.

Details zur Konfiguration des Bolero Terminals siehe Konfiguration eingehende Nachrichten. Die Option ist verfügbar, um die Zielverzeichnisse für eingehende Bolero-Nachrichten zusammen mit der erforderlichen Datei-Erweiterung für diese Nachrichtentypen anzugeben. Der Benutzer kann den OWN RID/BIC der Bank für den Empfang dieser eingehenden Bolero-Nachrichten angeben. Auch die Art des Druckformats kann angegeben werden.

In diesem Konfigurations-Panel kann der Benutzer das Triggerformat für die eingehenden SWIFT-Fileact-Nachrichten festlegen. Das XML-Format wird wie ein Header in die Nachricht eingepackt. Der MT-Body solcher Nachrichten wird intern an den Dienst “Incoming SWIFT” weitergeleitet und von diesem verarbeitet. Die Option ist auch verfügbar, um die Zielverzeichnisse für eingehende Fileact-Nachrichten sowie die erforderliche Datei-Erweiterung für diese Nachrichtentypen anzugeben.

Im allNETT Konfigurations-Panel kann der Benutzer die Art des Druckformats wählen. Es besteht die Möglichkeit, die automatische Verarbeitung eingehender allNETT-Nachrichten auszuwählen und die eingehenden Zielverzeichnisse zusammen mit der erforderlichen Dateierweiterung für diese Nachrichtendateien anzugeben. Der Nachrichtentyp/das Nachrichtenformat ist ein interner, proprietärer XSD-Standard.

Weitere Einzelheiten zu diesem Nachrichtentyp finden Sie unter SmartFoms. Mit dieser Option kann das Format der eingehenden SmartForms ausgewählt werden. Das am häufigsten verwendete Format/Typ ist “PDF”. Außerdem ist die Option verfügbar, die Zielverzeichnisse für eingehende Nachrichten zusammen mit der erforderlichen Datei-Erweiterung für diese Nachrichtentypen anzugeben. Da PDF-Dateien Passwörter enthalten können, können diese für einen einfachen Import der eingehenden Dateien ebenfalls gespeichert werden.