clx.tb-server schnittstellenbeschreibung zum is-kunden ... · für die ‚anonymous pipes...
TRANSCRIPT
CLX.TB-Server
Schnittstellenbeschreibung zum IS-Kunden-Modul V 4.0.1
CREALOGIX AG / September 2014
Diese Ausgabe ersetzt alle bisherigen Versionen. Bitte beachten Sie die Hinweise auf Seite 4
Seite 2 von 48
Inhaltsverzeichnis
Grundlagen ................................................................................................................................... 4
Gültigkeit / Versionsmanagement ................................................................................................ 4 Zusammenarbeit mit Herstellern der Clientsoftware .................................................................... 4
Einbindung in beliebige Kundensoftware ....................................................................................... 5
Ablauf der Kommunikation ......................................................................................................... 6 Zahlungsaufträge EZAG ............................................................................................................... 7 Zahlungsaufträge DTA / Eilzahlungen DTA / DTA ohne Unterschrift, etc. .................................... 7 Zahlungseinzüge LSV+, LSV+ ohne Unterschrift, SEPA-Lastschriftverfahren ................................. 7 Zahlungsaufträge Dispozahlung (Credit Suisse) ............................................................................ 7 Zahlungsaufträge im Format MT101 ............................................................................................ 7 Aufträge DD (Debit Direct).......................................................................................................... 7 Kontoauszüge und Depotauszüge ............................................................................................... 8 Intradays und Buchungsvormerkungen ........................................................................................ 8 Abholen ESR / VASR / EuroESR ................................................................................................... 8 Abholen IPI Gutschriftsanzeigen aus LSV+ in XML ...................................................................... 9 Abholen E-Dokumente ................................................................................................................ 9 Avisierungen in diversen Formaten .............................................................................................. 9 Multi-Banking generell ................................................................................................................ 9 Multi-Banking Credit Suisse Group ‚DirectLink International‘ .................................................... 10 Allgemeine Bemerkung.............................................................................................................. 10 Liste der verfügbaren Sessiontypen (abh. Finanzinstitut)............................................................ 11 Aufbau des Auftrags-Strings ...................................................................................................... 13 Anmerkungen zu Session 216 (Fall CS, NAB, Bank Leu) ............................................................. 15 Anmerkungen zu Session 221 (WIR Bank) ................................................................................. 16 Aufbau des Kommunikationsparameter Strings .......................................................................... 17 Aufbau der Datei für Systemmeldungen .................................................................................... 19 Interpretation: ........................................................................................................................... 19 Empfehlungen zur Auswertung .................................................................................................. 19
Sicherheit ....................................................................................................................................20
Open SSL ................................................................................................................................... 20 Ablauf der Installation ................................................................................................................ 21 Aufbau Auftrags-String für Schlüsselgenerierung ....................................................................... 22 Cryptomodul .............................................................................................................................. 23 Keypack nach Initialisierung zurücksenden ................................................................................ 24 Aufbau Auftrags-String für Keypack zurücksenden .................................................................... 24
Datenformate ..............................................................................................................................26
Fehlerbehandlung ........................................................................................................................27
Fehlercodes von IsClnt32.Exe ................................................................................................... 27
Inhalt Datenträger für Installation Anwenderkommunikation .........................................................28
INTERSYS.ISS............................................................................................................................. 28 LOGO.BMP ............................................................................................................................... 28 PARAMETERS.INI ...................................................................................................................... 28 SESSIONS.INI ............................................................................................................................ 30 Fileformat-ID ............................................................................................................................. 31
Seite 3 von 48
Ablauf- und Codebeispiele ...........................................................................................................33
Dialog Client-SW und IS-Modul ................................................................................................ 33 Beispiele zu Auftragsstring ......................................................................................................... 39 Beispiel Auftragsstring für Schlüsselgenerierung vor der Verarbeitung ....................................... 39 Beispiel Auftragsstring für Schlüsselgenerierung nach der Verarbeitung .................................... 39 Beispiel Kommunikations-Settings ............................................................................................. 39 Beispiel Auftragsstring vor SEND ............................................................................................... 40 Beispiel Auftragsstring nach SEND ............................................................................................. 40 Beispiel Auftragsstring vor RECEIVE .......................................................................................... 40 Beispiel Auftragsstring nach RECEIVE ........................................................................................ 41 Beispiel Auftragsstring vor Keypack zurücksenden ..................................................................... 41 Beispiel Auftragsstring nach Keypack zurücksenden .................................................................. 41 Beispiel eines Kontoauszuge MT940 Postfinance mit Referenz zu TIF-Datei .............................. 42 Beispiel Inhalt einer Protokolldatei mit Referenzen zu TIF- und GZ-Datei ................................... 43
Das Log des Kommunikationsmoduls IsClnt32.Exe ........................................................................44
Interpretation des Logs .............................................................................................................. 44
Tips und Informationen zum Kommunikationsmodul .....................................................................45
Änderungen Schnittstellenbeschreibung – September 2014 ...........................................................46
Index ...........................................................................................................................................47
Seite 4 von 48
Grundlagen Das IS-Kundenmodul dient zur sicheren und gesicherten Abwicklung des Datentransfers zwischen Finanzinstituten resp. dem Betreiber der CLX.TB-Server Plattform und einer beliebigen Branchen-Applikation / Firmenkunden-Software. Beispiele von unterstützten Sessions:
Kontoinformationen und Umsätze abholen
Informationen der Wertschriftendepots abholen
Change- und Devisenkurse abholen
Zahlungsaufträge senden Das IS-Kundenmodul arbeitet mit Formaten wie S.W.I.F.T., DTA, LSV+, EZAG, DD, VESR, VASR, EuroESR. Die Kommunikation ist je nach Anbieter/Finanzinstitut über TCP/IP (Internet oder DialUp1) oder analoge oder ISDN Modem Direktverbindung (Modem-Modem)
Das Sicherheitssystem ist in verschiedene Schichten eingebetet. Es werden u.a. die Standards und Vorgaben von TBSS und OpenSSL verwendet. Die Schnittstelle zu Programmen von Drittanbietern ist über ‚anonymous pipes’ realisiert. Über diese Interprozesskommunikation werden die vom Kommunikationsmodul benötigten Daten und Parameter über ein einfaches Protokoll ausgetauscht. Systemvoraussetzungen: Das IS-Kundenmodul ist als Programm IsClnt32.Exe verfügbar und einsetzbar unter MS Windows 2000, MS Windows XP, MS Windows 2003 und MS Windows Vista.
Gültigkeit / Versionsmanagement
Die vorliegende Version des IS-Kundenmodul resp. der Beschreibung der Schnittstelle ist ab sofort gültig. Sie ersetzt sämtliche bisherigen Module und Beschreibungen.
Zusammenarbeit mit Herstellern der Clientsoftware
Die CREALOGIX AG stellt dieses Modul (via Finanzinstitute) interessierten Herstellern von Client-Software Paketen kostenlos zur Verfügung. Diese können das Modul in ihre Software integrieren und beliebig an ihre Kunden weitergeben (Kopierrecht). Die CREALOGIX AG lehnt dabei für das Modul selbst und dessen Verwendung ausdrücklich jede Gewährleistung und Haftung ab. Die CREALOGIX unterstützt diese Hersteller beim Einbau und der Verwendung des IS-Moduls, wobei diese Unterstützung in jedem Fall kostenpflichtig ist.
1 Siehe auch ‚Aufbau des Kommunikationsparameter Strings’
Seite 5 von 48
Einbindung in beliebige Kundensoftware Das IS-Kundenmodul wird in Form eines ausführbaren Programms geliefert:
IsClnt32.Exe (Programm, im Arbeitsverzeichnis des Programms eines Drittherstellers)
Weiter benötigen sie die folgenden DLLs (Dynamic Link Libraries)
SslEay32.DLL und
LibEay32.DLL (OpenSSL Libraries2)
MSVCRT.DLL und
MFC42.DLL (als System Bibliotheken im Windows Systemverzeichnis, z.B. C:\WINNT\SYSTEM32; bitte beim Kopieren unbedingt die Versionsnummern allfällig bereits vorhandener Dateien beachten!).
Die Lieferung von CLX umfasst nur isclnt32.exe. Verwendet werden die MS Standard Libraries msvcrt.dll und mfc42.dll. Die ssleay32.dll und libeay32.dll (Open SSL) können bei Bedarf und falls nicht in eigener Entwicklungsumgebung bereits vorhanden bei CLX bezogen werden. 1. Aufruf des IS-Kundenmoduls erfolgt ohne Parameter. Achtung: Das
Kommunikationsmodul geht davon aus, dass seine ‚standard I/O-Handles’ den Handles für die ‚anonymous pipes’ entsprechen. (siehe MSDN ‚Creating a Child Process with Redirected Input and Output’. Dies entspricht der ‘normalen’ Verwendung von ‘anonymous pipes’.
Beispiel: C:\PROGRAMME\MYAPP\ISCLNT32.exe 2. Über die ‚anonymous pipes’ fragt IsClnt32.exe alle benötigten Informationen ab (siehe
Kapitel ‚Dialog über ‚anonymous pipes’’). Die benötigten Informationen entsprechen den in früheren Versionen über Dateien übergebenen Informationen (Auftrag.Ini, Modem.Ini, Schlüsseldateien usw.).
3. Das IS-Kundenmodul zeigt während der Ausführung in einer nicht bedienbaren Oberfläche den jeweiligen Status der Kommunikation an. Die hier gezeigten Informationen werden am Ende des Kommunikationsversuches in eine Log Datei geschrieben. Der Name der Log Datei wird durch die Kundensoftware festgelegt.
4. Nach Abschluss stellt das IS-Kundenmodul das Resultat der Kommunikation der Kundensoftware über die ‚anonymous pipes’ zur Verfügung und beendet sich.
5. Die Kundensoftware kann aufgrund des Resultates der Kommunikation ev. Massnahmen und Folgeverarbeitungen initiieren.
2 siehe Kapitel ‚Sicherheit’.
Seite 6 von 48
Ablauf der Kommunikation
Sehen Sie dazu auch das Beispiel im entsprechenden Kapitel (Seite 33). Die Kundensoftware bereitet alle nötigen Daten für den Kommunikationsauftrag vor (z.B.
generieren einer DTA Datei, speichern der Kommunikationsparameter, usw.).
Die Kundensoftware generiert zwei ‚anonymous pipes’ (input / output) und ‚biegt’ die ‚standard I/O handles’ auf die generierten ‚pipes’.
Die Kundensoftware startet das Kommunikationsmodul IsClnt32.exe
Die Kundensoftware setzt wieder die ‚standard I/O handles’
Das Kommunikationsmodul erstellt die Verbindung über die ‚anonymous pipes’ zur Kundensoftware und fragt über diese Verbindung die benötigten Parameter ab
Das Kommunikationsmodul führt den Kommunikationsauftrag durch. Dabei kann es von der Kundensoftware weiter Parameter oder Daten anfordern. Die Kundensoftware sollte also dem Kommunikationsmodul die benötigten Daten möglichst umgehend liefern, um die Kommunikationszeit möglichst kurz zu halten.
Das Kommunikationsmodul teilt der Kundensoftware das Resultat der Kommunikation/des Jobs über die Pipes mit.
Das Kommunikationsmodul teilt der Kundensoftware mit, dass es sich terminiert.
Die Kundensoftware wertet das Resultat der Kommunikation aus.
Seite 7 von 48
Zahlungsaufträge EZAG
Beim Zahlungsauftrag EZAG werden die Postkonto-Nummern aus der EZAG-Datei gelesen.
Das EZAG-File muss zwingend gem. POST-Spezifikationen, Kapitel 'Kommunikation mit Post-Systemen' im Format 'Magnetband Records 700 Bytes mit CR/LF übergeben werden.
Zahlungsaufträge DTA / Eilzahlungen DTA / DTA ohne Unterschrift, etc.
Daten im Diskettenformat gem. TK-Broschüre IBO 903 510 1.96 resp. 904 510 2.81. Zahlungen an Credit Suisse müssen eine DTA Auftraggeber Identifikation enthalten. Nach Absprache mit der Bank kann die Auftraggeber Kontonummer im IBAN Format geliefert werden.
Zahlungseinzüge LSV+, LSV+ ohne Unterschrift, SEPA-Lastschriftverfahren
Daten nach Format SIX Broschüre ‚LSV+; Anleitung für Zahlungsempfänger’. Bei einzelnen Finanzinstituten ist es möglich, während einer Übergangsfrist anstelle der Auftraggeber IBAN die konventionelle Kontonummer anzugeben. SEPA Direct Debit (SEPA-Lastschriftverfahren): Daten nach Format SIX Broschüre ‚ISO 20022 Payments; Schweizer Implemenation Guidelines für Customer-to-Bank Messages; SEPA Direct Debit (SEPA-Lastschriftverfahren; Customer Direct Debit Initiation und Payment Status Report‘
Zahlungsaufträge Dispozahlung (Credit Suisse)
Daten im DTA Diskettenformat wie ‚Zahlungsaufträge DTA’.
Zahlungsaufträge im Format MT101
Es gelten die Beschreibungen und Standards von S.W.I.F.T. Im Falle des Multibankings (s. unten) können Abweichungen durch die kontoführenden Institute verlangt werden. Erkundigen Sie sich beim Finanzinstitut, das die Multi-Banking-Funktion anbietet über spezielle Vereinbarungen.
Aufträge DD (Debit Direct)
Zum Übermitteln von Belastungsaufträgen DD der Post wird zusätzlich eine Datei mit den entsprechenden Postkonto-Nummern benötigt. (Grund: Der DD-Record enthält diese Information nicht, für die Berechtigungsprüfung auf Seite Post / Server wird diese jedoch benötigt.) Die Referenz dazu (inkl. Pfad) legen Sie im Feld 'Div. Informationen' (s. Seite 13 / Aufbau des Auftrags-Strings) fest.
Seite 8 von 48
Kontoauszüge und Depotauszüge
Daten im S.W.I.F.T. Format MT940 bzw. MT571. Hier sind allenfalls die detaillierteren Spezifikationen des jeweiligen (Ersteller-) Institutes zu beachten. Von Postfinance können Bilder zum Kontoauszug und Dateien im XML Format für die Auftragsavisierung beim Abholen der Kontoauszüge automatisch mitgeliefert werden. Ob und in welcher Form Bilddateien mitgeliefert wurden kann nach jeder erfolgreichen Durchführung von Session 200 (Abholen Kontoauszüge bei Postfinance) in der in Auftrag.Ini referenzierten Protokolldatei abgefragt werden.
Intradays und Buchungsvormerkungen
Daten im S.W.I.F.T. Format MT942 – als ‚Intradays’3 und als ‚echte Vormerkungen’4. Hier sind allenfalls die detaillierteren Spezifikationen des jeweiligen (Ersteller-) Institutes zu beachten. Dem ‚Abgleich’ der Vormerkungen ist besondere Aufmerksamkeit zu schenken. Wir empfehlen Kontoauszüge und Vormerkungen gleichzeitig abzuholen. Wo konfigurierbar sollten die Vormerkungen ‚FULL’ und nicht ‚incremental’ bezogen werden. So können vor einem Import von Daten die alten Vormerkungen gelöscht werden. Intradays von PostFinance können nur im Modus ‚Full‘ bezogen werden.
Abholen ESR / VASR / EuroESR
Die Datenfiles werden auf Post- und Bankseite kumuliert (konkateniert). Dies ist zu beachten, wenn der Kunde die Daten nicht regelmässig abholt. Beispiel: Wird dem Kunden täglich eine Datei zur Verfügung gestellt und holt dieser die Daten nur einmal wöchentlich ab, so erhält der Kunde eine Datei die fünf logische Dateien enthält – also auch 5 Totalrecords, die je nach Institut (z.B. Postfinance) sogar mit einem EOF (End of File) getrennt sein können. ESR und EuroESR unterscheiden sich in Datenaufbau und Inhalt wesentlich. Aus diesem Grund werden beide separat mit je einem eigenen Sessiontyp behandelt. Die Formatspezifikationen finden Sie in den entsprechenden Publikationen von Postfinance.
3 Intradays besitzen ein Buchungsdatum. Ein als Intraday gemeldeter Umsatz wird später in jedem Fall als Umsatz mit gleichem Buchungsdatum und Betrag in einem Kontoauszug gemeldet werden. Je nach Finanzinstitut sind aber allfällig enthaltene Referenzen in Intraday und Kontoauszug nicht identisch. Referenzen sollten deshalb für den Abgleich nur nach Absprache mit dem jeweiligen Finanzinstitut verwendet werden. 4 Vormerkungen sind ‚unsichere’ – also möglicherweise anfallende Umsätze. Da weder Betrag noch Valuta verbindlich sind, können ‚echte Vormerkungen’ kein Buchungsdatum tragen.
Seite 9 von 48
Abholen IPI Gutschriftsanzeigen aus LSV+ in XML
Daten im Format XML. Grundsätzlich gem. Spezifikation SIX (‚Gutschriftsanzeige in XML’). Speziell: die Datenfiles werden auf Bankseite kumuliert, so dass nur eine XML Datei empfangen wird. Bitte beachten Sie die Formatspezifikationen der Bank.
Abholen E-Dokumente
Beim Abholen von E-Dokumenten werden alle für den Kunden bereitstehenden Dateien/Dokumente heruntergeladen. Diese werden vom Kommunikationsmodul wie folgt, bzw. nach folgenden Regeln gespeichert: (a) Die Zieldatei wird im XML-Format abgelegt. (Empfehlung: Verwenden sie .XML als ‚Extenstion‘.)
Sie ist als eine Art ‚Inhaltsverzeichnis‘ zu verstehen. Die Bank liefert zu den E-Dokumenten Informationen (Metadaten) die Auskunft über Art und Inhalt der E-Dokumente geben.
(b) In’s Verzeichnis der Zieldatei werden auch die E-Dokumente gespeichert. (Aktuell sind diese ausschliesslich im PDF-Format.)
Ein Zielverzeichnis könnte also nach drei erfolgreichen Abhol-Versuchen so aussehen:
Informationen zum Format, Inhalt und Bedeutung/Interpretation der Daten erhalten sie von Ihrer Bank.
Avisierungen in diversen Formaten
Durch Postfinance und Banken werden dem Kunden Avisierungen in diversen Formaten angeboten (z.B. TAR.GZ-File mit XML Inhalt oder PDF Dateien). Das Ausgeberinstitut informiert sie kompetent über Inhalt und Bedeutung der jeweiligen Daten.
Multi-Banking generell
Beim Multi-Banking-Service handelt es sich um eine Dienstleistung der Partnerbank, indem diese ihre direkte (Intersystem)-Schnittstelle zum Austausch von Kontoauszügen und Zahlungsaufträgen (MT940 / MT101) für andere Banken aus dem SWIFT-Netz zur Verfügung stellt. Der administrative Ablauf ist beim jeweiligen Finanzinstitut zu erfragen. Das Verfahren bez. Datenaustausch richtig sich soweit als möglich nach diesem von UBS (X.Change), d.h. Sie erhalten über ein und denselben Kanal Kontoauszüge von verschiedenen Bankinstituten. Diese Auszüge sind mit BC-Nummer resp. SWIFT-Adresse referenziert. Ebenso müssen Zahlungsaufträge an solche Banken mit BC-Nummer / SWIFT-Adresse des kontoführenden Institutes versehen sein.
Seite 10 von 48
Multi-Banking Credit Suisse Group ‚DirectLink International‘
Der Multi-Banking Service von Credit Suisse, NAB und Clariden leu wird über einen gemeinsamen zusätzlichen Mandanten ‘DirectLink International’ (ID / BC-Nr. M0001) durchgeführt. D.h. es wird je ein separater Schlüssel für die CS-Partnerbanken und ‚DirectLink International‘ benötigt. Account Aggregation MT940: Die Meldungen werden dem Kundensystem so wie von der Drittbank geliefert
übergeben. Dabei findet sich die BIC der kontoführenden Bank im Header und die Kontonummer im Feld :25:. Es findet auf Anbieterseite eine Plausibilisierung statt. Festgestellte Fehler / Unregelmässigkeiten werden im entsprechenden Auszug mit einem zusätzlichen Umsatz mit Betrag Null und Fehlermeldung in der Buchungszeile geliefert.
MT942: Es gelten sinngemäss die gleichen Rahmenbedingungen wie unter MT940 beschrieben. Ob die Lieferung im Modus ‚incremental‘ oder ‚full‘ erfolgt hängt von der kontoführenden Bank ab und kann variieren.
Payment Forwarding MT100/101: Es gelten die von Fides bekannt gegebenen Formatanforderungen bezüglich
Header und Message-Inhalt. Es sind grundsätzlich nur Single-Payments erlaubt, Multiples werden zurückgewiesen. Eine übermittelte Datei kann jedoch aus mehreren Single-Payments bestehen.
MTXXX: Unter diesem Sessiontyp werden im Sinne eines Containers diverse (Text-)Meldungen an das Kundensystem weitergegeben: Einerseits werden alle eingelieferten Zahlungen so wie ins SWIFT-Netz eingespiesen zurück gemeldet. Andererseits können später eintreffende Meldungen der Korrespondenz- oder kontoführenden Bank mit dieser Session abgeholt werden (z.B. ‚request vor cancelation‘).
Verarbeitungsprotokoll: Es steht ein Verarbeitungsprotokoll zum Download zur Verfügung, das je nach stand der verarbeitung den Eingang der Zahlungen, Weiterleitung und mögliche Fehlermeldungen enthält. Es empfielt sich, dieses Verarbeitungsprotokoll regelmässig abzuholen, da je nach Verarbeitung bei der Bank des Begünstigten nachträglich noch wesentliche Meldungen eintreffen können.
Testmöglichkeiten Wenden Sie sich an ihre Kontaktperson bei Credit Suisse bezüglich jeweils verfügbarer Testverfahren.
Allgemeine Bemerkung
Bitte beachten Sie, dass nicht alle Services und Session mit allen Finanzinstituten verwendet werden können. Bevor Sie spezielle Services wie „Multi-Banking“ oder Sessions wie „Testzahlung“ oder „DTA ohne Unterschrift“ verwenden, sollten Sie sich beim betreffenden Institut über deren Verfügbarkeit erkundigen. Eine Tabelle mit den je Institut verfügbaren Sessions finden sie unter www.intersystem.ch/sessions.htm.
Seite 11 von 48
Liste der verfügbaren Sessiontypen (abh. Finanzinstitut)
Feldbeschreibung 'Sessiontyp' siehe Seite 14 / Aufbau des Auftrags-Strings
Identifikation Beschreibung Typ
100 Zahlungsaufträge DTA, LSV+ send
101 Zahlungsaufträge MT100/101 send 102 Zahlungsaufträge EZAG Standard (SAD) nur für Postfinance send
103 Aufträge DD nur für Postfinance send
104 - 109 Reserviert
110 Freiformat / Objekte allgemein send
111 DTA Eilauftrag send
112 Zahlungsaufträge EZAG prioritär nur für Postfinance send
1135 Zahlungsaufträge EZAG express nur für Postfinance send
1146 Zahlungsaufträge DTA, LSV+ ohne el. Unterschrift send
1157 Dispozahlung nur für Credit Suisse , NAB, Clariden Leu send
116 Zahlungsaufträge EZAG Lohn nur für Postfinance send
117 Zahlungsaufträge EZAG Lohn express nur für Postfinance send
118 Zahlungsaufträge DTA Einzel8 nur für Credit Suisse , NAB, Clariden Leu send
119 Z-aufträge DTA Einzel Eilauftr. nur für Credit Suisse , NAB, Clariden Leu send
120 Test Zahlungsaufträge DTA, LSV+ send
122 TEST-EZAG ‚Standard‘ nur für Postfinance send
123 Trade Finance (for future use) nur für Credit Suisse, NAB, Clariden Leu send
124 Factoring B2B (for future use) nur für Credit Suisse, NAB, Clariden Leu send
125 Factoring Insurance (for future use) nur für Credit Suisse, NAB, Clariden Leu send
128 SEPA Direct Debit Aufträge im Format ISO pain.008) send
129 Reserviert send
130 Zahlungsaufträge im Format ISO pain.001 send
133 TEST-DD nur für Postfinance send
200 Kontoauszüge MT940 receive
201 Abholen ESR, VASR receive
202 Reserviert
203 Abholen DD–Rückmeldungen9 nur für Postfinance receive 204 Depotauszüge MT571 receive
205 Abholen EuroESR nur für Postfinance receive
206 Reserviert
207 Abholen Auftragsavisierung im XML-Format10 nur für Postfinance receive
208 - 209 Reserviert
210 Freiformat / Objekte allgemein receive
211 Abholen Wechselkurse receive
215 Abholen Gutschriftsanzeigen EuroESR receive
216 Abholen DTA Ausführungsbestätigung im HTML-Format receive
5 Achtung: Bitte informieren Sie den Kunden, dass ein EZAG express mit zusätzlichen Spesen verbunden ist! 6 Die über diese Session eingelieferten Zahlungsaufträge werden von der Bank nicht automatisch weiterverarbeitet. Die Bank führt einen Zahlungsauftrag erst aus, wenn der Kunde den Auftrag mittels DTA/ LSV+ Auftragsformular bestätigt. 7 Dispozahlung (Credit Suisse): Siehe Seite 6 8 DTA Einzel: DTA Sammelauftrag mit Einzelverbuchung und Einzelanzeige 9 Eine Option ermöglicht ein automatisches Splitting der Daten nach Teilnehmernummer beim Abholen. 10 Die Daten werden komprimiert in einer .tar.gz Datei zur Verfügung gestellt.
Seite 12 von 48
217 Abholen Gutschriftsanz. IBAN/IPI im XML-Format (aus TA836) receive
218 Abholen Intradays MT942 receive
219 Abholen Kontoauszug im XML-Format11 nur für Postfinance receive
220 Abholen Vormerkungen MT942 receive
221 Abholen E-Dokumente12 receive 222 Abholen Gutschriftsanz. aus LSV+ IPI im XML-Format (aus TA875) receive
223 Abholen MTXXX / Container receive
224 Reserviert
225 Trade Finance (for future use) nur für Credit Suisse, NAB, Clariden Leu receive
226 Factoring B2B (for future use) nur für Credit Suisse, NAB, Clariden Leu receive
227 Factoring Insurance (for future use) nur für Credit Suisse, NAB, Clariden Leu receive
228-240 Reserviert
241 ISO Ausführungsbestätigung pain.00213 receive 242 reserviert
243 camt.05314 (Kontoauszug End of Day) receive
244 camt.05415 (Avisierungen: Gut- und Lastschrift, Ausführungs- Einzelbestätigung)
receive
245, 246 Reserviert
247 camt.05216 (Kontoauszug Intraday) receive
904 Wechsel Passwort receive 906 Vertrag sperren send
908 Reserviert
910 Keypack nach Initialisierung zurücksenden send17
912 - 920 Reserviert 950 Initialisierung Keypack lokal18
11 Die Daten werden komprimiert in einer .tar.gz Datei zur Verfügung gestellt. 12 Format abhängig vom Finanzinstitut. Beispiel: PostFinance: PDF; CS/NAB/Clariden Leu: XML mit Verweisen auf (eine/mehrere) PDF Datei(en). 13 Pain.002: Die Zieldatei enthält einer Liste der empfangenen Dateien. 14 Camt.053: Die Zieldatei enthält eine Liste der empfangenen Dateien. 15 Camt.054: Die Zieldatei enthält eine Liste der empfangenen Dateien. 16 Camt.052: Die Zieldatei enthält eine Liste der empfangenen Dateien. 17 Vor der Rücksendung des Schlüssels muss der Schlüssel ‚initialisiert’ werden (siehe Session 950). Bevor eine beliebige Session 100..908 möglich ist, muss das KeyPack erfolgreich an das Finanzinstitut zurückgeschickt und dort akzeptiert werden. 18 Dieser Sessiontyp ist insofern speziell, als dass keine Verbindung zum Server von Postfinance bzw. Bank aufgebaut wird. Nach Erhalt einer neuen Schlüsseldiskette (KeyPack) muss der Schlüssel über diese Session ‚initialisiert’ werden, bevor der Schlüssel elektronisch oder auf Diskette an das Finanzinstitut zurückgeschickt wird.
Seite 13 von 48
Aufbau des Auftrags-Strings
Der Auftrags-String entspricht in Aufbau und Inhalt exakt der in früheren Versionen benutzten Auftragsdatei.
Alle Felder müssen in fixer Länge und mit Delimiter Semicolon (;) dargestellt werden. Am Ende des Auftrags-Strings muss zwingend ein CR/LF stehen.
Bezeichnung Typ/Länge Beschreibung Beispiel
Auftragsnummer
Char 10 Auftragsidentifikation, kann durch Kundenapplikation zur eindeutigen Identifikation des Auftrages genutzt werden
0000000001
Partner_ID Char 15 z.B. Bankclearing-Nr. des Finanzinstitutes Darstellung linksbündig und mit b auffüllen
80709
Vertragsnummer
Char 50 VNr. des Telebankingvertrages mit dem entsprechenden Finanzinstitut (wird zusammen mit Schlüsselpack geliefert)
34-567.889
Div. Informationen
Char 128 Für Session ‚Lastschriftaufträge DD senden’ (103): Filename mit Liste der Kontonummern des Auftraggebers in editierter Form, jede Kontonummer mit CR/LF abgeschlossen. Für Session ‚Intradays abholen‘ (218): Enthält das Feld den Eintrag FULL anstelle von ‚Blanks’, so werden die Intradays nicht inkrementell sondern immer ‚full’ geliefert19. Für Session ‚DD Rückmeldungen abholen‘ (203): Enthält das Feld den Eintrag ‚SPLITT‘, so wird die empfangene Datei nach Teilnehmernummer gesplittet20. sonst: auffüllen mit b
C:\ACCOUNTS.LST
Passwort Char20 Passwort (verschleiert / s. 'Sicherheit') XY4Q2fr5X
Übermittlungsart
Char 1 S = Send, R = Receive S
Sessiontyp Char 3 s. Liste der möglichen, ein Subset davon wird zusammen mit dem Schlüsselpack vom Finanzinstitut übermittelt
100
internal use CLX Char 10 auffüllen mit b
internal use CLX Char 10 auffüllen mit b
*Status Char 1 b = noch nicht, 1 = übertragen, 9 = Fehler b
*Gestartet am Char 14 JJJJMMTTHHMMSS bbbbbbbbbbbbbb
*Beendet am Char 14 JJJJMMTTHHMMSS bbbbbbbbbbbbbb
*Fehlercode Char 20 Fehlercode von Partnersystem
*Fehlertext Char 80 Fehlertext von Partnersystem
19 Wir empfehlen den Wert FULL zu setzen. Für PostFinance ist der Eintrag FULL zwingend vorgeschrieben. 20 Bei der Angabe von SPLITT: Setzen Sie im Feld ‚Datei‘ nicht den Dateinamen, sondern den Namen dies Zielordners ein. Nach dem Empfang einer Datei wird diese im Zielordner mit folgendem Namen gespeichert: [DD Kundennummer].[aktuelles Datum].[Laufnummer].[Formattyp]. Format ‚aktuelles Datum‘: YYMMDD; mögliche Werte ‚Formattyp‘: DD2 oder ES2 (für DD Typ 2 bzw. DD-ESR Typ 2. Beispiel: ‚999991.081130.007.DD2‘.
Seite 14 von 48
Anzahl Vergütungen
Char 5 NNNNN, nur bei Senden von Zahlungen / entspricht dem Wert im Totalrecord
27
Totalbetrag Char 15 DTA-Notation, nur bei Senden von Zahlungen / entspricht dem Wert im Totalrecord
3480,50
(in DTA-Notation)
Datei Char128 Vollständiger Pfad (Laufwerk, Verzeichnis, Dateiname) der zu übertragenden Datei (senden oder empfangen). Achtung: Bitte Anmerkungen zu Session 216 (Fall CS, NAB, Bank Leu) . Siehe auch Fussnote zu Sessions 241, 243 und 244 in obenstehender Tabelle der Sessions.
C:\LOHN\ZAHLNG.D
TA
C:\TM\VESR_000.V
ES
C:\DEPOT\SWIFT.5
71
Identifikation der Bank Schlüssel
Char128 Identifikation der Schlüssel der Bank (früher Schlüsseldatei). Wenn das Kommunikationsmodul auf die Schlüssel zugreifen muss, so werden die Bank Schlüssel mit der hier eingesetzten Identifikation von der Kundensoftware angefordert. Die Kundensoftware ist in der Wahl der Identifikation frei.
C:\KOMM\KEY01.IS
S
Identifikation der Kommunikationsparameter Strings
Char128 Identifikation des Strings mit den Kommunikationsparametern (früher ‚Modem.ini’). Unmittelbar vor der Kommunikation fordert das Kommunikationsmodul mit der hier eingesetzten Identifikation den Kommunikationsparameter String an. Dieser enthält Angaben zur Kommunikationseinrichtung (Anwahl-Nr., Modemname, IP Adressen, etc.)
C:\KOMM\MODEM.IN
I
Logfile Char128 lw:\...\xxxxxxxx.xxx Pfad, Name inkl. Extention des Logfiles (das IS-Kundenmodul protokolliert alle Aktionen in diesem File)
C:\KOMM\DFUE.LOG
Protokolldatei für Dateiliste***
Char128 lw:\...\xxxxxxxx.xxx Pfad, Name inkl. Extention des Dateiprotokolles (das IS-Kundenmodul protokolliert alle erhaltenen Dateien mit Bildern zu Kontoauszügen und Auftragsavisierungen in diesem File)**
bbbbbbbbbbbbbb
Modul Char20 fix 'InterSystem' für IS_Kundenmodul InterSystem
Datum Char10 Erstellungsdatum des Files (DTA, EZAG, LSV, DD)
dd.mm.yyyy
Dateiname für Systemmeldung
Char80 lw:\...\xxxxxxxx.xxx Pfad, Name inkl. Extention einer Datei für Systemmeldungen. Die Meldungen werden entweder von Banken/Post als Systemmeldung zum Kunden geschickt (ehemals Feld ‚Mailtext‘ an dieser Stelle) und/oder vom IS-Kommunikationsmodul
C:\KOMM\SYSMSG.I
NI
Seite 15 von 48
generiert. Beschreibung des Dateiaufbaus: siehe Abschnitt ‚Aufbau der Datei für Systemmeldungen‘
CRLF Char2 Ende CRLF
* alle diese Angaben werden vom IS-Kundenmodul eingesetzt und als Antwort der Kundenanwendung übergeben. ** Postfinance liefert (wenn vorhanden) zu jedem Umsatz eine Bilddatei in TIF-Format (Extension .tif). Ein Umsatz und eine TIF-Datei sind über den Dateinamen und die Referenz im Umsatz eindeutig zugeordnet. Im Dateiprotokoll werden alle erhaltenen Dateien mit Pfad und Name aufgeführt. (Je Zeile eine Datei, jede Zeile mit CR/LF abgeschlossen.) Auftragsavisierungen sind keinem Umsatz zugeordnet (Dateiextension .new – diese Extension kann über einen Eintrag in WIN.INI ‚übersteuert’ werden21). Sie können durch einen Benutzer mit dem Postfinance Documents Manager angeschaut werden. Sehen Sie dazu das Beispiel auf Seite 42 *** Wird kein Name angegeben, so generiert das Kommunikationsmodul zusätzliche Informationen (Dateiname der Bilddatei oder Dateiname der Auftragsavisierung) im Feld :86: des zugehörigen Umsatzes, bzw. einen Null-Umsatz im Falle der Auftragsavisierung.
Anmerkungen zu Session 216 (Fall CS, NAB, Bank Leu)
Über Session 216 können DTA Empfangsprotokolle/Bestätigungen im Format HTML beim Finanzinstitut abgeholt werden. Damit die Protokolle der Institute CS, NAB oder Bank Leu in einem Browser angezeigt werden können, werden in einer festen Verzeichnisstruktur weitere Dateien (z.B. *.js, *.css, *.gif) benötigt. Diese Verzeichnisstruktur mit den Dateien wird durch das Kommunikationsmodul nach untenstehender Regel automatisch zur Verfügung gestellt. Zu beachten ist weiter, dass das Protokoll in vier Sprachen geliefert wird – je Sprache eine HTML Datei. Es gelten die folgenden Regeln: Wird durch die ‚Clientsoftware’ das DTA Empfangsprotokoll (Session 216) angefordert, so gibt diese einen Dateinamen im Format [lw:][pfad][dateiname] an (Feld ‚Datei’ im Auftrags-String). Beispiel: c:\programme\myapp\data\2004.02.29-01.ptk Holt das Kommunikationsmodul erfolgreich Daten beim Finanzinstitut ab, so wird:
unter dem Verzeichnis [lw:][pfad] die obengenannte Verzeichnisstruktur mit den benötigten Dateien angelegt (z.B. die Verzeichnisse „c:\programme\myapp\data\de“, „c:\programme\myapp\data\en“, usw.).
Das eigentliche Resultat wird in vier Dateien [dateiname].HTML (z.B. „2004.02.29-01.ptk.HTML“) gespeichert. Diese Dateien befinden sich in Unterverzeichnissen von [lw:][pfad], die sprachabhängig sind.
21 Um die Extension von *.new auf z.B. *.tar.gz zu ändern, fügen Sie in WIN.INI eine Section [InterSystem] mit einem Eintrag ‚AvisExtension=tar.gz’ ein.
Seite 16 von 48
Wenn Detailinformationen zu Zahlungsaufträgen (DTA/LSV/LSV+) vorliegen, so enthalten die vier obengenannten Dateien Links zu ebenfalls generierten neuen HTML Dateien.
Beispiel: Verlangt wird eine Datei „c:\programme\myapp\data\2004.02.29-01.ptk“. Nach erfolgreicher Kommunikation stehen die folgenden Dateien zur Verfügung:
c:\programme\myapp\data\en\2004.02.29-01.ptk.html
c:\programme\myapp\data\fr\2004.02.29-01.ptk.html
c:\programme\myapp\data\it\2004.02.29-01.ptk.html
c:\programme\myapp\data\de\2004.02.29-01.ptk.html Empfehlung:
Beachten Sie bei der Wahl des Namens der zu empfangenden Datei, dass das Resultat schlussendlich in vier Sprachen/Dateien in sprachabhängigen Unterverzeichnissen abgelegt wird und dass
bei der Wahl des Dateinamens (um die Eindeutigkeit eines Namens zu testen) die Dateien in den Unterverzeichnissen .\en, .\fr, .\it oder .\de geprüft werden müssen.
Anmerkungen zu Session 221 (WIR Bank)
Die Session ursprüngliche Session 211 wurde zu einer ‚E-Documents abholen‘ Session.erweitert. Informationen zu ‚E-Dokumente abholen‘ finden Sie im Kapital (weiter oben) ‚Ablauf der Kommunikation‘ unter ‚Abholen E-Dokumente‘.
Seite 17 von 48
Aufbau des Kommunikationsparameter Strings
Der Kommunikationsparameter String entspricht in Aufbau und Inhalt exakt der in früheren Versionen benutzten Script Datei mit den Kommunikations-Settings (Modem.ini).
Alle Keys (also COMTYP, MODEM, usw. ) müssen in Grossbuchstaben geschrieben sein, alle Eingaben (Zeilen) müssen mit einem CR/LF abgeschlossen werden.
Key Beschreibung
Beispiel
Verwenden wenn
NUI NUI des Anwenders für X.28 (falls vorhanden und erforderlich) sonst fix 'REVERSE'
NUI=muster COMTYP=TP
PWD Passwort zu NUI für X.28 (falls vorhanden und erforderlich) sonst fix 'CHARGE'
PWD=abcdef COMTYP=TP
NUA NUA des Kommunikationspartners (Post / Bank) für X.25-Kommunikation
NUA=12345600 COMTYP=TP
COMTYP Netzwerk Provider : TP Telepac (mit NUI oder Reverse Charge) MODEM direkte Modem/Modem–Verbindung TCPIP Verbindung über TCP/IP22
COMTYP=TP
COMTYP=MODEM
COMTYP=TCPIP
Immer
MODEM Name des Windows Modems (Name eines in der Windows Systemsteuerung definierten Modems). Bitte exakte Schreibweise beachten.
MODEM=
ZyXEL ISDN
X.75 64k0
COMTYP=TP
COMTYP=MODE
M
1CNTRY Ländercode der Anwahlnummer gem. Definitionen von Windows (Schweiz = 41 für 0041). 1. Teil der Anwahlnummer.
1CNTRY=41 COMTYP=TP
COMTYP=MODE
M
1AREA Vorwahl/Nummernkreis (z.B. ‚71‘ für ‚071‘ oder ‚1‘ für ‚01‘). 2. Teil der Anwahlnummer.
1AREA=71 COMTYP=TP
COMTYP=MODE
M
1PHONE Anwahlnummer ohne Ländercode und ohne (Bereichs-) Vorwahl. 3. Teil der Anwahlnummer. Im Beispiel würde die Anwahl auf die Nummer +41 (71) 3442801 gemacht.
1PHONE=344280
1 COMTYP=TP
COMTYP=MODE
M
CREATOR Identifikation der Applikation, die dieses File erstellt hat (max. 28 Zeichen). Vorgesehen für Info an Hotlineservice der Bank/Post
CREATOR=
MY
Application
Version 5.00
immer
DESTHOSTIP IP-Adresse des Servers von Bank/Post (Ziel- DESTHOSTIP= COMTYP=TCPI
22 Die Verbindung muss bereits hergestellt sein, z.B. über RAS-Dialer, Router oder Standleitung.
Seite 18 von 48
Server) oder eines Proxy (dieser muss die Adresse des Ziel-Servers kennen und eine Verbindung aufbauen)
193.20.164.99 P
DESTHOSTPORT
Portnummer des Ziel-Servers oder eines Proxy (siehe Anmerkungen unter DESTHOSTIP)
DESTHOSTPORT=
4000 COMTYP=TCPI
P
THISHOSTIP Fakultativ: IP-Adresse des ‚eigenen’ Rechners. Kann bei multihomed Systemen oder im Zusammenhang mit Restriktionen im Umfeld einer Firewall eingesetzt werden.
THISHOSTIP=
201.23.5.252 COMTYP=TCPI
P
THISHOSTPORT
Fakultativ: Portnummer des ‚eigenen’ Rechners. Kann im Zusammenhang mit Restriktionen im Umfeld einer Firewall eingesetzt werden.
THISHOSTPORT=
3999 COMTYP=TCPI
P
HTTPPRXYIP Fakultativ: IP-Adresse/Name eines HTTP Proxy HTTPPRYYIP=my
.proxy.ch
COMTYP=TCPI
P
HTTPPRXYPORT
Fakultativ: Port eines HTTP Proxy HTTPPRXYPORT=
3999
COMTYP=TCPI
P
HTTPPRXYUSR Fakultativ: Username für Login an HTTP Proxy HTTPPRXYUSR=e
ve
COMTYP=TCPI
P
HTTPPRXYPWD
Fakultativ: Passwort für Login an HTTP Proxy HTTPPRXYPWD=a
bc
COMTYP=TCPI
P
Die meisten Werte der Kommunikationssettings können bei der Initialisierung des KeyPacks über die Schlüsseldiskette eingelesen werden. Siehe Kapitel ‚Inhalt Datenträger für Installation Anwenderkommunikation’.
Seite 19 von 48
Aufbau der Datei für Systemmeldungen
Die Datei hat den Aufbau einer Windows INI-Datei: In einer Section „Auftragsnummer“ ist ein Wert ‚SysMsg’ enthalten. Mit „Auftragsnummer“ ist der Wert des ersten Feldes von Auftrag.Ini einzusetzen. Beispiel: [1501]
SysMsg=Das ist eine Systemmeldung vom Institut A!
[1503]
SysMsg=Das ist eine Systemmeldung vom Institut Z!
Interpretation:
Mit dem Auftrag Nr. 1501 wurde ein Institut angewählt, das die Systemmeldung „Das ist die Systemmeldung von Institut A“ liefert. Auftrag Nr. 1502 existiert nicht – oder dieses Institut hat zur Zeit keine Systemmeldung aktiv. Auftrag Nr. 1503 baute eine Verbindung zu einem Institut auf, das die Systemmeldung „Das ist die Systemmeldung von Institut Z!“ aktiviert hat.
Empfehlungen zur Auswertung
1. Sie können in allen Aufträgen von Auftrag.Ini immer den gleichen Dateinamen für die Systemmeldungen verwenden.
2. Löschen Sie eine evtl. bestehende Datei vor dem Aufruf von IsClnt32.Exe. 3. IsClnt32.Exe schreibt die Datei nur, wenn mindestens eines der angewählten Institute
eine Systemmeldung aktiv hat. 4. Systemmeldungen können beliebig lang sein. Wir empfehlen Ihnen die Verwendung
eines 255 Bytes langen Feldes. 5. Interpretieren Sie eine Datei wie eine INI-Datei. Es ist vorgesehen, in Zukunft noch
weitere Informationen in dieser Datei abzuspeichern. Ihre Applikation sollte diese ‚heute unbekannten’ Informationen ignorieren.
Seite 20 von 48
Sicherheit Im Folgenden soll ein grober Überblick über die mit Intersystem verwendete Sicherheitsverfahren gegeben werden. Durch die gezielte Kombination verschiedener Verfahren wie RSA, DES und OpenSSL kann ein Optimum an Sicherheit bei gleichzeitig (für den Anwender) guter Performance erreicht werden.
Die Sicherheit in der Kommunikation mit dem Finanzinstitut erfolgt im IS-Kundenmodul auf drei verschiedenen Ebenen:
o der Austausch von User-ID und Password als applikatorische Funktion o nach den Vorgaben von TBSS (RSA Public-Key, Hash-Funktionen, sowie DES) o Open SSL
Open SSL Für Open SSL werden die beiden folgenden DLLs benötigt (beide werden zusammen mit dem IS-Modul IsClnt32.exe von CLX ausgeliefert): - SslEay32.dll - LibEay32.dll Diese beiden DLL können von jedem Hersteller nach Belieben ab www.openssl.org selber generiert und benützt werden. Somit würde dem Gedanken von Open SSL am ehestens entsprochen. Zudem hat damit jeder Beteiligte die Sicherheit, dass es sich um Standards und nicht um ev. modifizierte DLLs handelt. Die von CLX zur Verfügung gestellten Dateien wurden ab Version 0.9.7b generiert.
Wichtig: Das IS-Com-Modul stellt zwar Funktionen für die Generierung von Public- und Private-Keys zur Verfügung. Die Aufbewahrung und Sicherung vor unberechtigtem Zugriff aller Sicherheitskriterien obliegt jedoch in jedem Fall der Client-Software. Unter Umständen ist es ratsam, dass die aufrufende Software mit
geeigneten Mitteln verifiziert, dass sie tatsächlich das IS-Com-Modul aufruft.
Seite 21 von 48
Ablauf der Installation
Der Kommunikationspartner (Finanzinstitut) liefert dem Anwender aufgrund einer Vereinbarung (Telebanking Vertrag) einen Datenträger (Diskette, Memory Stick, etc.) mit den notwendigen Schlüsseln, Angaben zu den Session Berechtigungen und Verfahren der Anwahl (z.B. IP-Adresse und Port Nummer, etc.).
Diese Informationen müssen auf dem System des Anwenders installiert werden. Das Installationsprogramm ist Sache des Herstellers der Anwendersoftware, wobei diesem durch die CLX resp. das Finanzinstitut ein Programm mit den Funktionen für Schlüsselgenerierung und ein Modul23 für die Verschleierung der Passworte der Schnittstellenfiles zur Verfügung gestellt wird (s. Beschreibung 'Cryptomodul').
Die aus diesem Prozess entstehenden Schlüsselinformationen werden durch das obengenannte Programm mit den Funktionen der Schlüsselgenerierung in die vom Partner gelieferte Schlüsseldatei gespeichert. Der Anwender muss diesen Datenträger mit der nachgeführten Schlüsseldatei an sein Finanzinstitut zurücksenden, die das Schlüsselverfahren mit diesem Kunden definitiv aktivieren wird. Bei einigen Instituten ist es wahlweise möglich die Datei via Kommunikationseinrichtung zurückzusenden. Ob dieses Verfahren möglich ist, wird vom Finanzinstitut bestimmt.(s. Beschreibung)
Die verschiedenen Sicherheitsmerkmale (Public Key der Bank, Private-Key und Passwort des Kunden, etc.) werden der Client-SW im Rahmen der Initialisierung übergeben. Diese ist für die sichere Aufbewahrung verantwortlich. Sie wird diese Daten jeweils für die Kommunikation an das IS-Com-Modul übergeben müssen.
Achtung: Das generieren der Schlüssel ist ein äusserst rechenintensiver Prozess. Wird ein neuer Schlüssel für eine 2048 Bit Verschlüsselung generiert, so kann das (je nach Rechnerleistung) mehrere Minuten dauern! Jeder Schlüssel muss aber auf einem Rechner nur einmal generiert werden, was bedeutet, dass ein weiterer Auftrag zur Schlüsselgenerierung ohne lange Wartezeit erledigt wird.
23 Das Modul zur Passwortverschleierung wird in Form vom C-Source-Code ausgeliefert (oder kann dieser
Beschreibung entnommen werden; s. Beschreibung 'Cryptomodul').
Seite 22 von 48
Aufbau Auftrags-String für Schlüsselgenerierung
Alle Felder müssen in fixer Länge und mit Delimiter Semicolon (;) dargestellt werden. Am Ende des Auftrags-Strings muss zwingend ein CR/LF stehen.
Bezeichnung Typ/Länge Beschreibung Beispiel
Auftragsnummer Char 10 Auftragsidentifikation, kann durch Kundenapplikation zur Eindeutigen Identifikation des Auftrages genutzt werden
0000000001
*Partner_ID Char 15 z.B. Bankclearing-Nr. des Finanzinstitutes Darstellung linksbündig und mit b auffüllen
80709
*Vertragsnummer Char 50 VNr. des Telebankingvertrages mit dem entsprechenden Finanzinstitut (wird zusammen mit Schlüsselpack geliefert)
34-567.889
Neues Passwort Char128 Passwort (verschleiert / s. 'Sicherheit') EEWsdt5SD
Init-Passwort Char20 Passwort (verschleiert / s. 'Sicherheit') XY4Q2fr5X
Internal use CLX Char 1 b
Sessiontyp Char 3 konstant 950 950
Internal use CLX Char 10 auffüllen mit b
Internal use CLX Char 10 auffüllen mit b
*Status Char 1 b = noch nicht, 1 = erfolgreich, 9 = Fehler b
Internal use CLX Char 14 auffüllen mit b
Internal use CLX Char 14 auffüllen mit b
*Fehlercode Char 20 Fehlercode (s. Liste)
*Fehlertext Char 80 Fehlertext
internal use CLX Char 5 auffüllen mit b
internal use CLX Char 15 auffüllen mit b
internal use CLX Char 128 auffüllen mit b
Schlüsseldatei (Schlüsselpack)
Char128 lw:\...\xxxxxxxx.xxx Pfad, Name inkl. Extention des Schlüsselpacks (Achtung: Hier wird tatsächlich eine Schlüsseldatei und nicht nur eine Identifikation verlangt.)
A:\InterSys.ISS
internal use CLX Char 128 auffüllen mit b
Logfile Char128 lw:\...\xxxxxxxx.xxx Pfad, Name inkl. Extention des Logfiles (das IS-Kundenmodul protokolliert alle Aktionen in diesem File)
C:\KOMM\DFUE.LOG
internal use CLX Char 128 auffüllen mit b
Modul Char20 konstant 'InterSystem' für IS_Kundenmodul InterSystem
internal use CLX Char10 auffüllen mit b
internal use CLX Char80 auffüllen mit b
CRLF Char2 Ende CRLF
* alle diese Angaben werden vom IS-Kundenmodul eingesetzt und als Antwort der Kundenanwendung übergeben.
Seite 23 von 48
Cryptomodul
Der Hersteller der Anwendersoftware erstellt (zum Beispiel ein C-) Modul zum Einbau in seine Software. Dieses Modul beinhaltet die Funktionen zum Verschleiern der Passwörter im Auftragsstring. Das folgende Listing kann als Vorlage benützt werden: // extern "C" evtl. bei C++ verwenden.
int FAR PASCAL _export nCryptPassword(char FAR * szCryptPw, char FAR
* szOpenPw)
{
// Funktion zum verschlüsseln von Passworten:
// szCryptPw = Output (20 + 1 Stellen reservieren !!)
// szOpenPw = Input (maximal 8 + 1 Stellen)
int i,i1, nCount = 0;
char a;
char szTempPw[9];
char szFilter[] =
{"97532468ACEGJLNQSUWYZXVTRPMKHFDB$$$$$$$$$$$$$$$$"};
srand( (unsigned)time( NULL ) );
i1 = rand() % 255 + 1;
szCryptPw[0] = 1;
szCryptPw[1] = szCryptPw[2] = a = (char) i1;
szCryptPw[2] &= '\x0f';
szCryptPw[1] >>= 4;
szCryptPw[1] &= '\x0f';
for (i = 0; i < 8; i++) szTempPw[i] = szOpenPw[i] ^ a; szTempPw[8] = 0;
for (i=0;i<8;i++) {
szCryptPw[i+3] = szCryptPw[11+i] = szTempPw[i];
szCryptPw[i+3] >>= 4;
szCryptPw[i+3] &= '\x0f';
szCryptPw[i+11] &= '\x0f';
if (rand() % 2) szCryptPw[i+3] |= '\x10';
if (rand() % 2) szCryptPw[i+11] |= '\x10';
szCryptPw[i+3] = szFilter[szCryptPw[i+3] ];
szCryptPw[i+11] = szFilter[szCryptPw[i+11]];
}
for (i=0;i<3;i++) {
if (rand() % 2) szCryptPw[i] |= '\x10';
szCryptPw[i] = szFilter[szCryptPw[i]];
}
szCryptPw[19] = 0;
return 0;
}
Seite 24 von 48
Keypack nach Initialisierung zurücksenden
Um den Ablauf zu beschleunigen, ist es möglich - je nach Institut - die Schlüsseldatei via Kommunikation zurückzusenden. Ob diese Funktion möglich ist oder nicht wird durch die Bank/Post beim Erstellen der SchlüsselDiskette bestimmt. Die Information steht in der Datei PARAMETERS.INI, die mit der Schlüsseldatei mitgeliefert wird. Wenn der Eintrag "KEYPACK=ISDFUE" in der Section [InterSystem] vorhanden ist, so kann die Datei via Kommunikation zurückgesendet werden. Die Möglichkeit, die Datei via Datenträger zurückzusenden besteht in jedem Fall!
Aufbau Auftrags-String für Keypack zurücksenden
Alle Felder müssen in fixer Länge und mit Delimiter Semicolon (;) dargestellt werden. Am Ende des Auftragsstrings muss zwingend ein CR/LF stehen.
Bezeichnung Typ/Länge Beschreibung Beispiel
Auftragsnummer Char 10 Auftragsidentifikation, kann durch Kundenapplikation zur Eindeutigen Identifikation des Auftrages genutzt werden
0000000001
Partner_ID Char 15 z.B. Bankclearing-Nr. des Finanzinstitutes Darstellung linksbündig und mit b auffüllen
80709
Vertragsnummer Char 50 VNr. Des Telebankingvertrages mit dem entsprechenden Finanzinstitut (wird zusammen mit Schlüsselpack geliefert)
34-567.889
Neues Passwort Char128 Passwort (verschleiert / s. 'Sicherheit') EEWsdt5SD
Init-Passwort Char20 Passwort (verschleiert / s. 'Sicherheit') XY4Q2fr5X
internal use CLX Char 1 B
Sessiontyp Char 3 konstant 910 910
internal use CLX Char 10 auffüllen mit b
internal use CLX Char 10 auffüllen mit b
*Status Char 1 b = noch nicht, 1 = erfolgreich, 9 = Fehler B
internal use CLX Char 14 auffüllen mit b
internal use CLX Char 14 auffüllen mit b
*Fehlercode Char 20 Fehlercode (s. Liste)
*Fehlertext Char 80 Fehlertext
internal use CLX Char 5 auffüllen mit b
internal use CLX Char 15 auffüllen mit b
Schlüsseldatei (Schlüsselpack)
Char128 lw:\...\xxxxxxxx.xxx Pfad, Name inkl. Extention des Schlüsselpacks (Achtung: Hier wird tatsächlich eine Schlüsseldatei und nicht nur eine Identifikation verlangt.)
A:\InterSys.ISS
Identifikation der Kommunikationsparameter Strings
Char128 Identifikation des Strings mit den Kommunikationsparametern (früher ‚Modem.ini’). Unmittelbar vor der Kommunikation fordert das Kommunikationsmodul mit der hier eingesetzten Identifikation den Kommunikationsparameter String an. Dieser enthält Angaben zur Kommunikationseinrichtung (Anwahl-Nr.,
C:\KOMM\MODEM.INI
s. Anmerkung nächste Seite!
Seite 25 von 48
Modemname, IP Adressen, etc.)
Logfile Char128 lw:\...\xxxxxxxx.xxx Pfad, Name inkl. Extention des Logfiles (das IS-Kundenmodul protokolliert alle Aktionen in diesem File)
C:\KOMM\DFUE.LOG
internal use CLX Char 128 Auffüllen mit b
Modul Char20 Konstant 'InterSystem' für IS_Kundenmodul InterSystem
internal use CLX Char10 Auffüllen mit b
Dateiname für Systemmeldung
Char80 lw:\...\xxxxxxxx.xxx Pfad, Name inkl. Extention einer Datei für Systemmeldungen
C:\KOMM\SYSMSG.INI
CRLF Char2 Ende CRLF
* diese Angaben werden vom IS-Kundenmodul eingesetzt und als Antwort der Kundenanwendung übergeben.
Seite 26 von 48
Datenformate Bei den unterstützten Datenformaten handelt es sich wo immer möglich um verbreitete Standards. Um Missverständnisse zu vermeiden, wird in diesem Papier auf eine Beschreibung der einzelnen Formate verzichtet. Anstelle dessen wird in der folgenden Tabelle auf die offizielle Dokumentation des jeweiligen Herausgebers verwiesen. Datentyp Beschreibung Dokumentation zu beziehen bei
DTA Zahlungsaufträge im Format DTA www.six-interbank-clearing.com
EZAG Zahlungsaufträge im Format SAD (Bandformat) www.postfinance.ch
SWIFT MT100/101 Einzelzahlungen (DirectLink International / CS) Fides
LSV+ Lastschriftverfahren Banken www.six-interbank-clearing.com
ESR-LSV+ Gutschriftsanzeigen aus LSV+ im Typ 3 Format www.six-interbank-clearing.com
XML-LSV+ Gutschriftsanzeigen aus LSV+ in XML www.six-interbank-clearing.com
DD Lastschriftverfahren Post (Bandformat) www.postfinance.ch
VESR/BESR Verfahren für Einzahlungsscheine mit Referenz (Bank- und Post-ESR sind identisch)
www.postfinance.ch
VASR Verfahren für Auszahlungsscheine mit Referenz www.postfinance.ch
SWIFT MT940 Kontoauszüge SWIFT-Format (inkl. ind. Feld 86 gem. OMIKRON/Multi-Cash)
SWIFT-Manual resp. MC-Handbuch OMIKRON
SWIFT MT942 Vormerkposten SWIFT-Format do.
OMIKRON MT940 Kontoauszüge SWIFT-Format mit zusätzlichen Angaben bez. Umsätzen in Non-Swift-Sätzen
MC_Handbuch OMIKRON
OMIKRON MT942 Vormerkposten SWIFT-Format mit zusätzlichen Angaben bez. Umsätzen in Non-Swift-Sätzen
do.
SWIFT MT571 Wertschriften-Depotinhalt SWIFT-Format SWIFT-Manual oder MC_Handbuch OMIKRON
SWIFT MT572 Wertschriften-Depotbewegungen SWIFT-Format do.
Wechselkurse Format gem. (Ersteller-) Institut Spezifikation (Ersteller-) Institut
Freiformat / Objekte
freier Inhalt und freies Format IS-Kundenmodul vollzieht lediglich die gesicherte Übertragung, es müssen individuelle Absprachen zwischen Kom-Partner und Anwender bezüglich Inhalt und Zweck getroffen werden.
keine notwendig
TIF Bilder zu Kontoauszügen (e-Kontoauszug Postfinance)
keine notwendig
Auftragsavisierung Gezippte Gruppe von Dateien in den Formaten XML, XSL, DTD und TIF. Postfinance liefert einen XML-Tool (Yellow Net Viewer) zur Anzeige der Daten.
keine notwendig
EuroESR Gutschriftsanzeigen von Postfinance www.postfinance.ch
EuroESR Gutschriftsanzeigen im XML Format Offen
Gutschriften IBAN/IPI (aus TA 836)
Gutschriftsanzeigen aus IBAN/IPI Zahlungen im XML Format
www.six-interbank-clearing.com
DTA Ausführungs-bestätigung
Ausführungsprotokoll von DTA Zahlungsaufträgen im HTML Format
Keine notwendig
Kontoinformationen
Kontoinformationen in PDF Keine notwendig
ISO20022 pain.001, pain.002, pain.008 www.six-interbank-clearing.com
Bitte konsultieren Sie die jeweils aktuellen Versionen bei den ausgebenden Stellen.
Seite 27 von 48
Fehlerbehandlung Im Zusammenhang mit der Kommunikation können verschiedene Fehler auftreten. Grundsätzlich sind sie in die Gruppen aufzuteilen:
Schlüssel und Berechtigungen (bei Senden von Aufträgen zusätzlich fehlerhafte Totale)
Übertragungsprobleme Seite Partnersystem (Server bei Banken/Post)
Übertragungsprobleme Seite Anwendersystem (Modem, Leitung, etc.)
Fehlercodes von IsClnt32.Exe
Die Fehlermeldungen mit Fehlercode > 99 werden vom Kommunikationsmodul selbst generiert. Sie werden in englischer Sprache ins Log geschrieben. Die folgende Tabelle enthält zur besseren Verständlichkeit die deutsche Übersetzung der entsprechenden Texte. Fehlercod
e
Fehlertext
01 Keine Berechtigung
02 Unbekanntes Konto
03 Verbindung zur Datenbank unterbrochen
04 File existiert bereits
05 Ungültiger Filename
06 Keine Daten vorhanden
07 Ungültige Parameter
08 Ungültiger Vertrag
09 Ungültige Clearingnummer
10 Keine gültige Identifikation
11 Sessiontyp nicht unterstützt
12 Unbekannter Sessiontyp
13 Falsches Passwort
14 Falscher Bankschlüssel
15 Falscher Kundenschlüssel
16 Vertrag gesperrt
17 Keys noch nicht eingelesen
18 Keine Berechtigung, altes Kundenmodul
19 Unbekanntes Depot
20 Keypack konnte nicht eingelesen werden
23 Bereichsfehler in den Kontodaten
110 ZahlungsAuftragsstring nicht gefunden.
111 Konnte im DTA kein Auftraggeberkonto finden.
112 Fehler beim Zugriff auf die zu sendende Datei.
...
Die vorliegende Liste ist nicht vollständig.
Seite 28 von 48
Inhalt Datenträger für Installation Anwenderkommunikation Durch Postfinance und Banken werden direkt an den Anwender die folgenden Dateien geliefert.
Intersys.ISS: Schlüsseldatei (Keypack, enthält u.a. die Vertragsnummer)
Logo.BMP: Bitmap mit Logo des Finanzinstitutes
Parameters.INI: Datei mit Informationen zu allen möglichen Kommunikationsparametern des Institutes
Sessions.INI: Datei mit Angabe der erlaubten Sessiontypen Aus Kompatibilitätsgründen können weitere Dateien auf dem Datenträger gespeichert sein. Diese Dateien sollten aber in keinem Falle interpretiert werden.
INTERSYS.ISS
InterSys.ISS ist die eigentliche Schlüsseldatei (Keypack). Sie enthält Informationen zum InterSystem Vertrag sowie vom Finanzinstitut generierte Schlüssel. Die Schüsseldatei muss nach Erhalt über eine Session 950 ‚initialisiert’ werden, d.h. mit vom Kundenrechner generierten Schlüsselinformationen angereichert werden. Die veränderte Datei muss (auf Datenträger oder über Session 910) an das Finanzinstitut zurückgeschickt werden. (Siehe Beschreibungen der Session 950 ‚Initialisierung Keypack’ und Session 910 ‚Keypack nach Initialisierung zurücksenden.)
LOGO.BMP
Bitmap mit dem Logo des Finanzinstitutes – zur freien Verwendung in der Applikation eines Drittherstellers.
PARAMETERS.INI
Parameters.INI enthält alle Informationen, die eine Applikation eines Drittherstellers benötigt, um die Verbindung zum Finanzinstitut herstellen zu können. Wenn ein Finanzinstitut Verbindungen über Telepac, Modem direkt (Modem-Modem) und TCP/IP zulässt, so befinden sich also in der Datei alle benötigten Informationen für alle möglichen Zugänge in dieser Datei (z.B. NUA, Einwahlnummer für ‚Modem direkt’, IP Adresse, usw.) Die folgenden Informationen können in einer Datei Parameters.INI in der Section [InterSystem] gefunden werden: Feld Bedeutung Beispiel
BCNR BC Nummer der Bank BCNR=8391
Name Name der Bank Name=CLX Bank
Ort Ort/Anschrift der Bank Ort=Solothurn
LogoHoehe Höhe der BitMap – konstant 74 LogoHoehe=74
LogoBreite Breite der BitMap – konstant 164 LogoBreite=164
DTA Default DTA Identifikation DTA=CLX01
COMTYP ‚for future use’ COMTYP=TCPIP
KEYPACK Wenn vorhanden: Schlüssel el. zurücksenden. KEYPACK=ISDFUE
IPHOST-I IP Adresse der Bank (Internet Zugang) IPHOST-I=212.111.16.117
Seite 29 von 48
PORTHOST-I Port der Bank (Internet Zugang) PORTHOST-I=4226
IPHOST-D IP Adresse der Bank (‚Direkt’-Zugang) IPHOST-D=212.111.16.117
PORTHOST-D Port der Bank (‚Direkt’-Zugang) PORTHOST-D=4336
USEX25 Kommunikation über X.28/X.25 möglich? Y/N USEX25=N
USEM-M Kommunikation über Modem-Modem möglich? Y/N
USEM-M=N
USETCP Kommunikation über TCP/IP möglich? Y/N USETCP=Y
USEDUP Nur für TCP/IP: Kommunikation auf Einwahlknoten der Bank möglich? Y/N
USEDUP=N
USEINT Nur für TCP/IP: Kommunikation über Internet zur Bank möglich? Y/N
USEINT=Y
VERSION Versionsnummer der Daten – konstant 1. VERSION=1
REVERSE Nur für Telepac: Reverse Charge? Y/N REVERSE=N
WINTELM Telefonnummer im kanonischen Format für Modem-Modem Anwahl
WINTELM=+423 () 1234500
WINTELT Telefonnummer im kanonischen Format für TCP/IP Anwahl (Einwahlknoten des Finanzinstitutes)
WINTELT=+41 (800) 800900
ISDN-TXT Textfeld: Liste der Unterstützten ISDN Protokolle zur Anzeige in einem Assistenten (Modem-Modem Kommunikation)
ISDN-TXT= ISDN X.75, ISDN
V.120
NUA NUA der Bank im Falle Telepac-Kommunikation NUA=42110041
REG1 User ID für RAS DialUp zum Einwahlknoten der Bank. User ID ist von rechts-nach-links dargestellt (HUGO OGUH)
REG1=diresu
REG2 Passwort für RAS DialUp zum Einwahlknoten der Bank. Darstellung wie User ID (HUGO OGUH)
REG2=trowssap
PHONEBOOK PhonBook Entry Name (Name des Telefonbucheintrages) im Falle Dial Up auf Einwahlknoten des Institutes
PHONEBOOK=VP Bank
1. Beispiel einer Datei Parameters.INI [InterSystem]
BCNR=8999
Name=CLX Test-Finanz
Ort=Solothurn
LogoHoehe=74
LogoBreite=164
DTA=CLX01
COMTYP=TCPIP
KEYPACK=ISDFUE
IPHOST-I=115.111.115.111
PORTHOST-I=4116
USEX25=N
USEM-M=N
USETCP=Y
USEDUP=N
USEINT=Y
VERSION=1
REVERSE=N
Dieses Beispiel zeigt die Informationen eines Institutes, das nur über TCP/IP, Zugang über Internet erreichbar ist.
Seite 30 von 48
2. Beispiel einer Datei Parameters.INI [InterSystem]
BCNR=8999
Name=CLX Test-Finanz
Ort=Solothurn
LogoHoehe=74
LogoBreite=164
DTA=CLX01
COMTYP=TCPIP
IPHOST-D=112.118.14.218
PORTHOST-D=4117
USEX25=Y
USEM-M=Y
USETCP=Y
USEDUP=Y
USEINT=N
VERSION=1
REVERSE=Y
WINTELM=+41 (800) 123456
WINTELT=+423 () 9651133
ISDN-TXT=ISDN X.75
NUA=42318840
REG1=diresu
REG2=trowssap
PHONEBOOK=DialUp_CLX
Dieses Beispiel zeigt die Informationen eines Institutes, das über Telepac, Modem direkt (Modem-Modem) und über TCP/IP (Zugang über einen bankeigenen Einwahlknoten) erreichbar ist. Dieses Finanzinstitut akzeptiert keine el. Rücksendung der Schlüssel.
SESSIONS.INI
In dieser Datei sind die möglichen Sessions gespeichert. Format: In einer Section [Sessions] sind die folgenden Werte gespeichert: Wert Beschreibung Beispiel Count Anzahl berechtigte Sessions Count=7 Text[n] Freier Text, der den Sessiontyp
‚umschreibt’. Text[n] wurde in Sessions.Ini eigefügt, um die Daten ‚lesbarer’ zu machen. Wir empfehlen diese Information nicht auszuwerten.
Text1=ESR/ASR (n=1..Count)
Value[n] Numerischer Wert (Fileformat-ID), der die berechtigte Session umschreibt (siehe nachfolgende Tabelle)
Value7=10 (bedeutet: ‚Kontoauszüge abholen’ erlaubt)
Beispiel einer Datei Sessions.INI:
Seite 31 von 48
Fileformat-ID
Die Fileformat-ID wird in Sessions.INI, wie auch in OffWingF.txt verwendet. Es gelten die Werte wie gem. Tabelle: Fileformat-ID Typ Bezeichnung
1 DD DD-Auftrag
2 ESR ESR/ASR-Daten
3 DTA Zahlungen
4 Frei Freiformat abholen
5 Frei Freiformat senden
6 Kurse Fremdwährungskurse
7 LSV LSV-Auftrag
8 MT101/MT100
SWIFT MT101/MT100 Zahlungen
9 MT571 Depotdaten
10 MT940 Kontoauszüge
11 EZAG EZAG-Auftrag
17 DD-Aus DD-Auslieferung
18 MT942 Intradays
19 DTA DTA Eilauftrag
22 Euro ESR Euro ESR
25 DTA DTA ohne Unterschrift
26 HTML DTA Ausführungsbestätigung
27 IBAN-Aus IBAN/IPI Gutschriftsanzeigen
28 DTA Dispozahlung
29 MT942 Buchungsvormerkungen
30 LSV+ Lastschriften ohne el. Unterschrift
31 EZAG EZAG Lohn
32 EZAG EZAG Lohn Express
33 XML XML Avisierungen
34 PDF Dokumente in PDF
35 LSV+/IPI Gutschriftsanzeigen
36 DTA DTA Test
37 LSV+ Lastschriften
38 LSV+-P LSV+-Protokoll
39 LSV+-A LSV+ Avisierungen im ESR-Format
Seite 32 von 48
42 Frei
43 MTXXX Container-Messages (aus SWIFT)
44 LSV+ LSV+ Test
47 ‚TFS‘ XML Trade Finance (Send)
48 ‚FB2BS‘ XML Factoring B2B (Send)
49 ‚FINSS‘ XML Factoring Insurance (Send)
50 ‚TFR‘ XML Trade Finance (Receive)
51 ‚FB2BR‘ XML
Factoring B2B (Receive)
52 ‚FINSR‘ XML Factoring Insurance (Receive)
53 SEPA DD SEPA Direct Debit (Send)
OffWingF.txt Diese Datei ist aus Kompatibilitätsgründen auf der Schlüsseldiskette enthalten. Sie soll nicht mehr ab Schlüsseldiskette interpretiert werden. Bei jedem Kommunikationsversuch wird aber diese Datei auch aktuell vom InterSystem Server des Finanzinstitutes geladen und auf dem Kundenrechner mit dem Namen ‚OffWingF.txt’ gespeichert. Diese aktuelle Datei entspricht dem Format von OffWingF.txt auf der Schlüsseldiskette: Delimited File mit Trennzeichen Semicolon (“;”). Die erste Zeile enthält die Feldnamen. Feldname Inhalt Bankformate_ID Leer Partner_ID Nicht verwendet Fileformate_ID Format-ID gemäss Tabelle unten Absender_ID Nicht verwendet Datenträger Nicht verwendet Länge Nicht verwendet CRLF Nicht verwendet Total_Datum Nicht verwendet Total_Konto Nicht verwendet Total_Währung Nicht verwendet Neuer_File Nicht verwendet Suffix Nicht verwendet Sessionstyp Nicht verwendet Modul Nicht verwendet
Aktiv 1 = aktiv 2 = nicht unterstützt
Version Nicht verwendet Status Nicht verwendet Modul_ID Nicht verwendet
Seite 33 von 48
Ablauf- und Codebeispiele
Dialog Client-SW und IS-Modul
Grundsatz: Datenstrings über die Pipe werden immer mit terminierendem ASCII 0 übermittelt. Ein
Datenstring hat also immer die Länge 'Stringlänge + 1'. CR/LF wird hier mit ‚\r\n’ abgekürzt.
Tipps: Senden und empfangen Sie Daten über die anonymous Pipes mit einem Read oder Write Befehl: Definieren sie die Buffer gross genug (z.B. 4 KB).
Die Strings, die Schlüssel enthalten, können auch Zeichen ASCII 0 enthalten. Behandeln Sie die Informationen also nicht als ‚zero terminated strings’.
‚Ident’ String Nach erfolgreichem ‚connect’ meldet sich IsClnt32.exe mit folgendem String: Beispiel eines ‚Ident’ Strings: ?o\r\nIdent:\r\nIsClnt32.Exe\r\nInterSystem Communication Version 2.50407(o)\r\n2.50407(o)\r\n07.04.2003\r\nnnnnnn
Bedeutung: Zeile Inhalt Bedeutung 1. Zeile ?o ?=Anfrage
o=Order Aufforderung, den ersten Auftrags-String zu übermitteln.
2. Zeile Ident: Konstante 3. Zeile IsClnt32.Exe Modulname 4. Zeile InterSystem
… Versionsbezeichnung (langes Format)
5. Zeile 2.50407(o) Versionsbezeichnung (kurzes Format) 6. Zeile 07.04.2003 Modul Datum 7. Zeile nnnnnn ‚for future use’
Antwort: Die Kundensoftware übermittelt den ersten Auftrags-String: Ein Auftragsstring muss mit Länge 1'176 übermittelt werden: (4 Bytes Header + 1'169 Bytes Daten + CR/LF (2 Bytes) + terminierendes ASCII 0). Header: „[nn]“, nn = 2stellige Laufnummer, beginnend mit ‚00’. Die Kundensoftware hat die Möglichkeit, den ‚Ident’ String mit der Angabe eines Verzeichnisses (anstelle des Auftrags-Strings) zu beantworten. Die Antwort muss in diesem Fall in der Form „DATAPATH=[Verzeichnisname]“ mit abschliessendem CR/LF an das Kommunikationsmodul geschickt werden. Beispiel einer Antwort:
DATAPATH=d:\myapp\is-modul\data\r\n
Dadurch verwendet das Kommunikationsmodul als Basisverzeichnis (zum Generieren von Temporären und internen Dateien und Verzeichnissen) nicht mehr das Verzeichnis, in dem IsClnt32.exe gespeichert ist, sondern den übergebenen DATAPATH. Das Kommunikationsmodul beantwortet die Angabe des DATAPATH mit: ?o\r\nnew datapath: ‘[Verzeichnisname]’
Seite 34 von 48
Auftrags-Anforderungs-String Das Kommunikationsmodul sendet den ‚Auftrags-anforderungs-String’ als Antwort auf einen von der Kundensoftware übermittelten Auftrags-String. Damit wird bestätigt, dass der Auftrag Nr. n erfolgreich empfangen und akzeptiert wurde und dass der nächste Auftrag übermittelt werden kann Beispiel eines ‚Auftrags-Anforderungs-Strings’: ?o\r\ngot order no 1 Bedeutung:
Zeile Inhalt Bedeutung 1. Zeile ?o ?=Anfrage
o=Order Aufforderung, den ersten Auftrags-String zu übermitteln.
2. Zeile got order no 1
Auftrag Nr. 1 wurde erfolgreich empfangen.
Antwort: Die Kundensoftware übermittelt den nächsten Auftrags-String (siehe oben) oder nur ein ‚Fragezeichen’ („?\r\n“). Das Fragezeichen bedeutet, dass keine weiteren Aufträge vorhanden sind und dass die Kundensoftware auf ‚Anfragen’ oder ‚Informationen’ des Kommunikationsmodules wartet. Gleichzeitig ist das ‚Fragezeichen’ eine Bestätigung, dass die vorangegangene Information des Kommunikationsmodules richtig empfangen und interpretiert werden konnte. Kommunikationsparameter Anforderung Während der ‚Erledigung’ der Kommunikationsaufträge kann das Kommunikationsmodul ein oder mehrere Male die Kommunikationsparameter anfordern. Beispiel eines Anforderungsstrings: ?m\r\nKOMMPARAM1 Bedeutung:
Zeile Inhalt Bedeutung 1. Zeile ?m ?=Anfrage
m=Kommunikationsparameter Aufforderung die Kommunikationsparameter zu übermitteln.
2. Zeile KOMMPARAM1 Identifikation des Kommunikationsparameter Strings (aus dem Auftrags-String)
Antwort: Die Kundensoftware übermittelt den Kommunikationsparameter-String.
Seite 35 von 48
Anfordern der InterSystem Schlüssel, Teil ‚SpecValue1’ Während der ‚Erledigung’ der Kommunikationsaufträge kann das Kommunikationsmodul ein oder mehrere Male die InterSystem Schlüssel anfordern. Beispiel eines Anforderungsstrings: ?s\r\nSpecValue1 Bedeutung: Zeile Inhalt Bedeutung 1. Zeile ?s ?=Anfrage
s=InterSystem Schlüssel Aufforderung die InterSystem Schlüssel zu übermitteln.
2. Zeile SpecValue1 Identifikation der gewünschten Schlüssel Antwort: Die Kundensoftware übermittelt die angeforderten Schlüssel. Spezialfall: Bei der Initialisierung einer Schlüsseldiskette ist es möglich, dass die Schlüssel noch nicht existieren. In diesem Fall gibt die Kundensoftware nur ein Fragezeichen („?\r\n“) zurück. Anfordern der InterSystem Schlüssel, Teil ‚SpecValue2’ Während der ‚Erledigung’ der Kommunikationsaufträge kann das Kommunikationsmodul ein oder mehrere Male die InterSystem Schlüssel anfordern. Beispiel eines Anforderungsstrings: ?s\r\nSpecValue2 Bedeutung: Zeile Inhalt Bedeutung 1. Zeile ?s ?=Anfrage
s=InterSystem Schlüssel Aufforderung die InterSystem Schlüssel zu übermitteln.
2. Zeile SpecValue2 Identifikation der gewünschten Schlüssel Antwort: Die Kundensoftware übermittelt die angeforderten Schlüssel.
Seite 36 von 48
Anfordern der Bank/Postfinance Schlüssel Während der ‚Erledigung’ der Kommunikationsaufträge kann das Kommunikationsmodul ein oder mehrere Male die Schlüssel des Finanzinstitutes anfordern. Beispiel eines Anforderungsstrings: ?f\r\nKEY769-190968 Bedeutung: Zeile Inhalt Bedeutung 1. Zeile ?f ?=Anfrage
s=Postfinance/Bank Schlüssel Aufforderung die Schlüssel zu übermitteln.
2. Zeile KEY769-190968
Identifikation der Bank/Postfinance Schlüssel (wie im Auftrags-String übergeben)
Antwort: Die Kundensoftware übermittelt die angeforderten Schlüssel. Übermitteln des Auftrags Resultates Nach der ‚Erledigung’ eines Kommunikationsauftrages übermittelt das Kommunikationsmodul den Auftrags-String an die Kundensoftware zurück. Der Auftrag-String ist nun mit dem Kommunikationsergebnis ergänzt. Beispiel eines Ergebnisstrings: !o\r\n00\r\n221…. Bedeutung: Zeile Inhalt Bedeutung 1. Zeile !o !=Information
o=Order / Auftrag Das Resultat des Auftrages wird übermittelt.
2. Zeile 00 Nummer des Auftrages (aus der Übermittlung des Auftrags-Strings der Kundenapplikation an das Kommunikationsmodul)
3. Zeile [Auftrags-String]
Der Auftrags-String mit terminierendem CR/LF
Antwort: Die Kundensoftware quittiert die Information mit einem ‚Fragezeichen’ („?\r\n“). Das Fragezeichen bedeutet, dass die Kundensoftware auf ‚Anfragen’ oder ‚Informationen’ des Kommunikationsmodules wartet. Gleichzeitig ist das ‚Fragezeichen’ eine Bestätigung, dass die vorangegangene Information des Kommunikationsmodules richtig empfangen und interpretiert werden konnte. Übermitteln der InterSystem Schlüssel, Teil ‚SpecValue1’ Nach der ‚Erledigung’ eines Auftrages ‚Initialisierung Schlüssel’ kann das Kommunikationsmodul die InterSystem Schlüssel an die Kundensoftware übermitteln.
Seite 37 von 48
Diese Schlüssel werden vom Kommunikationsmodul während der Durchführung eines Kommunikationsauftrages wieder angefordert. Beispiel eines Strings: !s\r\nSpecValue1\r\n221…. Bedeutung: Zeile Inhalt Bedeutung 1. Zeile !s !=Information
s=InterSystem Schlüssel Die InterSystem Schlüssel werden vom Kommunikationsmodul an die Kundensoftware übermittelt..
2. Zeile SpecValue1 Identifikation der gewünschten Schlüssel 3. Zeile [Schlüssel] Schlüssel Antwort: Die Kundensoftware quittiert die Information mit einem ‚Fragezeichen’ („?\r\n“). Das Fragezeichen bedeutet, dass die Kundensoftware auf ‚Anfragen’ oder ‚Informationen’ des Kommunikationsmodules wartet. Gleichzeitig ist das ‚Fragezeichen’ eine Bestätigung, dass die vorangegangene Information des Kommunikationsmodules richtig empfangen und interpretiert werden konnte. Übermitteln der InterSystem Schlüssel, Teil ‚SpecValue2’ Ablauf gleich wie das Übermitteln der InterSystem Schlüssel, Teil ‚SpecValue1’. Als Schlüsselidentifikation wird die Konstante ‚SpecValue2’ verwendet. Übermitteln der Bank/Postfinance Schlüssel Nach der ‚Erledigung’ eines Auftrages ‚Initialisierung Schlüssel’ übermittelt kann das Kommunikationsmodul die Schlüssel des Finanzinstitutes an die Kundensoftware. Diese Schlüssel werden vom Kommunikationsmodul während der Durchführung eines Kommunikationsauftrages wieder angefordert. Achtung: Wenn das Kommunikationsmodul diesen Schlüssel an die Applikation übermittelt, wurde die Schlüsseldatei bereits beschrieben. (Zu Beachten: Je nach Betriebssystem und Konfiguration kann das (physische) Schreiben von und in Dateien durch das Betriebssystem verzögert werden.) Beispiel eines Strings: !f\r\n221…. Bedeutung: Zeile Inhalt Bedeutung 1. Zeile !s !=Information
f=Schlüssel Finanzinstitut (Bank/Postfinance) Die Schlüssel des Finanzinstitutes werden vom Kommunikationsmodul an die Kundensoftware übermittelt..
2. Zeile [Schlüssel] Schlüssel Antwort:
Seite 38 von 48
Die Kundensoftware quittiert die Information mit einem ‚Fragezeichen’ („?\r\n“). Das Fragezeichen bedeutet, dass die Kundensoftware auf ‚Anfragen’ oder ‚Informationen’ des Kommunikationsmodules wartet. Gleichzeitig ist das ‚Fragezeichen’ eine Bestätigung, dass die vorangegangene Information des Kommunikationsmodules richtig empfangen und interpretiert werden konnte. Übermitteln der ‚Kommunikationsmodul Terminiert’ Ankündigung Nach der ‚Erledigung’ aller Kommunikationsaufträge übermittelt das Kommunikationsmodul einen String um das Terminieren des Kommunikationsmodules anzumelden. Dadurch kann die Kundensoftware feststellen, dass das Kommunikationsmodul ordnungsgemäss beendet wird. Die Kundensoftware sollte aber zusätzlich zu diesem String auch den Prozess IsClnt32.exe selber überwachen (also feststellen können, wann dieser Prozess terminiert). Beispiel des Strings: $bye\r\n Bedeutung: Zeile Inhalt Bedeutung 1. Zeile $bye $=Terminiere
bye=Konstante Das Kommunikationsmodul wird gleich terminieren.
2. Zeile leer Antwort: Die Kundensoftware gibt keine Antwort auf diesen String des Kommunikaitonsmodules.
Seite 39 von 48
Beispiele zu Auftragsstring
ACHTUNG! Aus Gründen der Darstellung wurden die folgenden Beispiele auf mehrere
Zeilen verteilt. In Wirklichkeit enthält jedes Auftragsstring nur ein CRLF am Ende des Files!
Beispiel Auftragsstring für Schlüsselgenerierung vor der Verarbeitung
499 ; ;
;$üäöplto8uhh
;_?iuujz ; ;950; ; ; ; ;
; ;
; ; ;
;C:\OFFWINGS\ISPKOMM\KEYPAC.ISP
;
;C:\OFFWINGS\log\ZVDF.Log
;
;InterSystem ; ;C:\OFFWINGS\SYSMSG.TXT
Beispiel Auftragsstring für Schlüsselgenerierung nach der Verarbeitung
499 ;1 ;12789
;$üäöplto8uhh
;_?iuujz ; ;950; ; ;1; ;0
;Installation erfolgreich durchgeführt.
; ; ;
;C:\OFFWINGS\ISPKOMM\KEYPAC.ISP
;
;C:\OFFWINGS\log\ZVDF.Log
;
;InterSystem ; ;C:\OFFWINGS\SYSMSG.TXT
Beispiel Kommunikations-Settings
NUA=9999040653
COMTYP=MODEM
MODEM=Standard 28800 bps Modem
1CNTRY=41
1AREA=848
1PHONE=828836
CREATOR=Office-Wings 2.0 (SL 5)
Seite 40 von 48
Beispiel Auftragsstring vor SEND
477 ;1 ;120
;
;__
{fnl{)))) ;S;110; ; ; ; ;
; ;
; ; ;C:\OFFWINGS\SEND\00001.BMP
;C:\OFFWINGS\ISPKOMM\KEYPAC.ISP
;C:\OFFWINGS\transfer\modem.ini
;C:\OFFWINGS\log\ZVDF.Log
;
;InterSystem ; ;C:\OFFWINGS\SYSMSG.TXT
Beispiel Auftragsstring nach SEND
477 ;1 ;120
;c:\konto.txt
;_?ROGER ;S;110; ;
;1;19960620105737;19960620105855; ;Der Auftrag
ist erfolgreich ausgefuehrt worden
; ; ;C:\OFFWINGS\SEND\00001.BMP
;C:\OFFWINGS\ISPKOMM\KEYPAC.ISP
;C:\OFFWINGS\transfer\modem.ini
;C:\OFFWINGS\log\ZVDF.Log
;
;InterSystem ; ;C:\OFFWINGS\SYSMSG.TXT
Beispiel Auftragsstring vor RECEIVE
476 ;1 ;120
;
;___•bjh•---- ;R;200; ; ; ; ;
; ;
; ; ;C:\OFFWINGS\RECEIVE\00107000.EMP
;C:\OFFWINGS\ISPKOMM\KEYPAC.ISP
;C:\OFFWINGS\transfer\modem.ini
;C:\OFFWINGS\log\ZVDF.Log
;
;InterSystem ; ;C:\OFFWINGS\SYSMSG.TXT
Seite 41 von 48
Beispiel Auftragsstring nach RECEIVE
476 ;1 ;120
;c:\konto.txt
;_09{fnl{)))) ;R;200; ;
;9;19960620105405;19960620105505;0006 ;Keine Daten
vorhanden
; ; ;C:\OFFWINGS\RECEIVE\00107000.EMP
;C:\OFFWINGS\ISPKOMM\KEYPAC.ISP
;C:\OFFWINGS\transfer\modem.ini
;C:\OFFWINGS\log\ZVDF.Log
;
;InterSystem ; ;C:\OFFWINGS\SYSMSG.TXT
Beispiel Auftragsstring vor Keypack zurücksenden
4 ;769 ;113512
;UPZNQBBDKGGVGYU6222
;UPZEEMMMMGGX6TS7522 ;S;910; ; ; ; ;
; ;
; ; ;D:\OFFWINGS\TESTSB\ISPKOMM\0076900.ISP
;D:\OFFWINGS\TESTSB\ISPKOMM\0076900.ISP
;D:\OFFWINGS\TESTSB\transfer\00010000.ini
;D:\OFFWINGS\TESTSB\log\ZVDF.Log
;
;InterSystem ; ;C:\OFFWINGS\SYSMSG.TXT
Beispiel Auftragsstring nach Keypack zurücksenden
4 ;769 ;113512
;7UL68TT63Y3B5MABFLF
;7M3PCPCPCAA57ST6XY3 ;S;910; ;
;1;19980428194714;19980428194754; ;Der Auftrag ist
erfolgreich ausgefuehrt worden ; ;
;D:\OFFWINGS\TESTSB\ISPKOMM\0076900.ISP
;D:\OFFWINGS\TESTSB\ISPKOMM\0076900.ISP
;D:\OFFWINGS\TESTSB\transfer\00010001.ini
;D:\OFFWINGS\TESTSB\log\ZVDF.Log
;
;InterSystem ; ;C:\OFFWINGS\SYSMSG.TXT
Seite 42 von 48
Beispiel eines Kontoauszuge MT940 Postfinance mit Referenz zu TIF-Datei
:20:ANFANGUMS
:25:1/25-9779-8
:28:00001
:60F:C991130CHF10000,00
:61:9912011201C100,00FMSC12345//NOREF
20000702123412123412364656789012
:86:GIRO AUS KONTO 30-349-0 KPT / CPT KRANKENKASSE BERN
Bild: C:\OFFWINGS\Images\20000702123412123412364.TIF
:61:9912011201C900,00FMSC23451//NOREF
12345678901234567890123456789000
:86:GIRO AUS KONTO 80-500-4 CREDIT SUISSE ZURICH
:61:9912021201D500,00NMSC34215//NOREF
20000702123412123412365456789111
:86:14647 SCHWEIZER. MOBILIAR VERSICHERUNGSGES. BUNDESGASSE 35
POSTFA
CH 3001 BERN
Bild: C:\OFFWINGS\Images\20000702123412123412365.TIF
:61:9912021201D1470,00NMSC09837//NOREF
69675325345276577890123456781111
:86:46-1999-2 RAIFFEISENBANK HAUENSTEIN-IFENTHAL HAUENSTEIN
:61:9912021201D30,00NMSC88765//NOREF
61111125345276577890123456789012
:86:1-65-4 SWISSCOM AG M-P GST BIEL BAHNHOFPLATZ 2501 BIEL/BIENNE
:61:9912031203D3,00FMSC13335//NOREF
14231423142134213890123456789012
:86:TREIBSTOFFBEZUG VOM 26.11.99 KARTE NR. 12312355 AVIAMAT, SELF-
SER
VICE BERN
:61:9912061206D200,00FMSC18885//NOREF
19999949494949467890123456789012
:86:AUFTRAG DEBIT DIRECT KUNDENNUMMER 1000002 ROBERT SCHNEIDER SA
GRA
NDS MAGASINS 2501 BIEL/BIENNE REFERENZNUUMMER 000135487621 RECHNU
NG VOM 22.11.99
:61:9912161216D80,00FMSC22285//NOREF
22223331114949467890123456789012
:86:BARGELDBEZUG VOM 14.12.99 KARTE NR. 1231235502 BERNER
KANTONALBAN
K BERN
:61:9912171217C1000,00FMSC22555//NOREF
22555666114949467890123456789012
:86:EINZAHLUNGSSCHEIN
:61:9912201220D400,00NMSC22775//NOREF
22777886614949467890123456789012
:86:YELLOW NET AUFTRAG 3 TRANSAKTION(EN)
:61:9912221222D200,00FMSC20005//NOREF
20000001114949467890123456789012
:86:YELLOW NET ZAHLUNGSANWEISUNG SCHWEIZ. BANKVEREIN MUSTER PAUL
:61:9912221222D500,00FMSC20099//NOREF
20099881114949463330123456789012
Seite 43 von 48
:62F:C991130CHF8617,00
Beispiel Inhalt einer Protokolldatei mit Referenzen zu TIF- und GZ-Datei
Name und Speicherort der Protokolldatei ist in autrag.ini angegeben
C:\MyApplication\Images\20000245583.tif
C:\MyApplication\Avis\Avis000713.new
Seite 44 von 48
Das Log des Kommunikationsmoduls IsClnt32.Exe *** IsClnt32 - Version 13.Jan.99 Start: 15.01.1999 14:43:17
Order 1 found. Line used: ZyXEL ISDN X.75 64k0 Make Call to T00848888800 CallState: dialtone
CallState: dialing
CallState: proceeding
CallState: connected
Connect successful Provider: Direct connection. > |203|203|902|013769|092111133|133uKTLiJOvyn9z0NuZOxuhwuojcw4
< |100|100|902|1344RkzkCut6GvRJSKB5DEX9Yc190FelACrBu-fMF7fc-uo
Request session 908
> |4|4|908|
Request for file sent
< |34|34|908|131offwingf.txt.111133|127589|
Confirm on request to receive file received
> |8|8|.......8
Filetransfer : 0 % done (0 of 589)
Filetransfer : 100 % done (589 of 589)
File transferred successfully.
Request session 200 > |36|36|200|04616 1 105.580-38|1270|023|024|
Request for data (16 1 105.580-38) sent
< |54|54|200|13194000769111133.199901151447.16110558038|127312
Confirm on request to receive file received
> |8|8|.......2
Filetransfer : 0 % done (0 of 312)
Filetransfer : 100 % done (312 of 312)
File transferred successfully.
Response: IS Server - Der Auftrag wurde erfolgreich ausgefuehrt. ()
Drop ordered
Drop completed
No more orders found. Orders completed.
Drop ordered
Drop completed
End: 15.01.1999 14:43:47
Interpretation des Logs
Auf jeder Zeile des Logs wird die aktuelle Zeit vermerkt. Nach diesem Zeitstempel folgt ein Logeintrag, der eine der folgenden drei Bedeutungen haben kann:
Ausgehende Meldung (String, der an den COM-Port gesendet wird): Zeile Beginnt mit Zeichen '>' .
Seite 45 von 48
Eingehende Meldung (String wurde vom COM-Port geliefert): Zeile beginnt mit Zeichen '<' .
Rest: Information / Interpretation des Kommunikationsmoduls. Ja nach Auftragstyp und Kommunikationsart und Kommunikationsausgang weicht das Log teilweise oder wesentlich von der abgebildeten Datei ab. Interpretation des Logs aus einer Kommunikation mit einem Institut direkte Modem-Modem Verbindung, ISDN X.75 mit einem ZyXEL ELITE Modem; senden einer Datei mit Zahlungsaufträgen: Versionsnummer und Erstellungsdatum des Kommunikationsmoduls. Auftragsstring und Konfigurationsinformationen werden gelesen. Angabe des Benutzen Windows Modems Angabe der Anwahl (hier wird die Nummer 0 0848 888 800 angewählt) Anwahl erfolgreich, das Modem hat eine Verbindung zum 'Zielmodem' hergestellt. Es handelt sich um eine direkte Modem-Modem Verbindung (in diesem Falle ISDN). Die
Verbindung zum ISP-Server ist also jetzt bereits hergestellt. Erst von diesem Zeitpunkt an ist der Server von Bank/Post in die Kommunikation involviert.
Nach dem Login fordert das Kommunikationsmodul vom Server Informationen an. Erst jetzt können Kontoauszüge angefordert werden. Die Datei wurde erfolgreich übertragen. Das Kommunikationsmodul terminiert.
Tips und Informationen zum Kommunikationsmodul
Das Modul legt ein Arbeitsverzeichnis 'ISClient' (als Unterverzeichnis des Verzeichnisses von IsClnt32.Exe) an. Dieses Verzeichnis, einzelne oder alle Dateien dieses 'ISClient'-Verzeichnisses dürfen gelöscht werden, wenn IsClnt32.Exe nicht aktiv ist. Um in Problemfällen Hilfe zur Rekonstruktion zu bieten, nutzt das Kommunikationsmodul dieses Verzeichnis intensiv zur Daten- und Informationssicherung.
Das Kommunikationsmodul legt zur Speicherung von Daten die Verzeichnisse .\Avis und .\Images an (als Unterverzeichnisse des Ordners, in dem IsClnt32.Exe gespeichert ist.
Die aktuelle Version des 32B Moduls ist auf dem Web unter www.intersystem.ch (Downloads) veröffentlicht.
Fragen und Informationen senden Sie an developer @crealogix.com.
Seite 46 von 48
Änderungen Schnittstellenbeschreibung – September 2014
Neuer Sessiontyp für camt.052 nachgeführt.
Seite 47 von 48
Index 1 1AREA 17 1CNTRY 17 1PHONE 17 A Abholen ESR / VASR 8 Ablauf der Kommunikation
6 Ablaufbeispiele 33 anonymous pipes 5 Anwahl 45 Anwahlvervahren 21 Anwender 28 Anwendersystem 27 Assistent 29 Aufruf 5 Aufträge DD 7 Auftraggeberkonto 27 Auftraggebers 13 Auftragsfile 23, 45 Auftragsidentifikation 13 Auftragsnummer 13, 22,
24 Auftragsstring 39 Auftragsstring 13, 22, 24 Auftragsstring 40 Auftragsstring 40 Auftragsstring 46 Auftragstyp 45 Avis 45 B BAD 7 BAD Rückmeldungen 11 Bankclearing-Nr 13 Bankschlüssel 27 BCNR 28 Beendet 13 Beispiel 29, 30 Berechtigungen 27 BESR 26 Bitmap 28 BVItb-servers 4 C Clearingnummer 27 Codebeispiele 33 COM-Port 45 COMTYP 17, 28 CREATOR 17 Cryptomodul 23 D Dateiliste 14 Datenformate 26
Datum 14 DD 11, 26, 31 DD Rückmeldungen 11 DD senden’ 13 Delimited File 32 Delimiter 13 Depot 27 Depotauszüge 8, 11 Depotbewegungen 26 Depotinhalt 26 DES 20 [email protected]
45 Dialog 33 Diskette 28 Dispozahlung 7, 11, 12 Download 45 DTA 11, 26, 27, 28, 31 E E-Dokumente 9, 12 Einwahlknoten 29 Einzugsaufträge LSV 7 End of File 8 ESR 8, 11, 31 EuroESR 8 EZAG 11, 26, 31 EZAG express 11 EZAG express1 11 EZAG prioritär 11 F Fehlerbehandlung 27 Fehlercode 13, 22 Fehlertext 13, 22 Fileformate Id 31
53 32 Filename 27 Freiformat 11, 26 G Gestartet 13 Grundlagen 4 Gültigkeit 4 H handles’ 6 I Identifikation 27 Images 45 individuelle Absprachen 26 Initialisierung 12, 24 Init-Passwort 22, 24 Installation 21 Installation Anwender-
Kommunikation 28
Interpretation 44 Intersys.ISS 28 INTERSYS.ISS 28 IPHOST-D 29 IPHOST-I 28 ISClient 45 IsClnt32.Exe 5, 45 ISDFUE 28 ISDN-TXT 29 ISO 20022 Payments 7 K kanonisches Format 29 Keypack 12, 24, 27, 28, 41 Keys 27 Kommunikation 27 Kommunikationsart 45 Kommunikationsparameter
28 Kommunikationsparameter
Strings 17 Kommunikationspartner 21 Konfigurationsinformatione
n 45 Konto 27 Kontoauszüge 8, 11, 26 Kundenschlüssel 27 Kurse 31 L Ländercode 17 Lastschriftaufträge 13 Lastschriftverfahren 26 Log 44 Logeintrag 44 Logfile 14, 22, 25 Login 45 Logo.BMP 28 LOGO.BMP 28 LogoBreite 28 LogoHoehe 28 LSV 11, 26, 31 M Mailtext 14, 25 MFC42.DLL 5 MODEM 17 Modem Settings 14, 17,
24, 39 Modem-Modem 45 Modul 22 MSVCRT.DLL 5 MT100 11 MT571 11, 31 MT940 11, 31
Seite 48 von 48
MT942 11 N Name 28 Neues Passwort 22, 24 Non-Swift-Sätzen 26 NUA 17, 29 NUI 17 Nummernkreis 17 O Objekte 11, 26 OffWingF.txt 31 OffWingP.txt 24 OMIKRON MT940 26 OMIKRON MT942 26 Open SSL 20 Ort 28 P Parameter 27 Parameters.INI 28 PARAMETERS.INI 28 Partner_ID 13, 22, 24 Partnersystem 27 Password 20 Passwort 12, 13, 22, 27 PDF-Format 9 PHONEBOOK 29 PORTHOST-D 29 PORTHOST-I 29 Postkonto-Nummern 7 Primary-Verbindung 17 PTT-Spezifikationen 7 Public-Key 20 PWD 17 R Receive 13 REG1 29 REG2 29 REVERSE 29 REVERSE CHARGE 17 Routing 17 RSA 20 S SAD 7, 11 Schlüssel 27 Schlüsseldatei 14, 22, 24 Schlüsselgenerierung 21,
39 Schlüsselinformationen 21 Schlüsseln 21 Schnittstellenfiles 21 Semicolon 32 Send 13
SEPA Direct Debit 7, 11, 32
SEPA-Lastschriftverfahren 7, 11
Session 128 11
Sessionberechtigungen 21 Sessions
100 11 101 11 102 11 103 11 110 11 112 11 113 11 114 11 115 11 122 11 133 11 200 11 201 11 202 11 203 11 204 11 205 11 210 11 211 11 215 11 904 12 906 12 908 12 910 12, 28 950 12, 28
Sessions.INI 28, 31 SESSIONS.INI 30 Sessiontyp 11, 13, 22, 24,
27, 28 Sicherheit 20 Sicherheitsmerkmale 21 Status 13, 22, 24 Support 45 SWIFT MT571 26 SWIFT MT572 26 SWIFT MT940 26 SWIFT MT942 26 Systemmeldungen 19 Systemsteuerung 17 T TBSS 20 TCP/IP 29 Telebankingvertrag 21 Telefonbucheintrag 29
Telepac 29 TEST-DD 11 TEST-EZAG 11 Totalbetrag 14 Totale 27 Totalrecords 8 U Übermittlungsart 13 Übertragungsprobleme 27 Umsätzen 26 USEDUP 29 USEINT 29 USEM-M 29 User-ID 20 USETCP 29 USEX25 29 V VASR 8, 11, 26 Verbindung 27 Vergütungen 14 Verschleiern der Passwörter
23 Verschleierung der
Passworte 21 VERSION 29 Versionsmanagement 4 Versionsnummer 45 Vertrag 27 Vertrag sperren 12 Vertragsnummer 13, 22,
24, 28 VESR 26 Vormerkposten 26 Vorwahl 17 W Wechsel Passwort 12 Wechselkurse 11, 26 Windows Modems 17, 45 WINTELM 29 WINTELT 29 www.intersystem.ch 45 X X.25-Kommunikation 17 Z Zahlungsaufträge 11, 26 Zahlungsaufträge DTA 7 Zahlungsaufträge EZAG 7 Zahlungsauftragsfile 27 Zeitstempel 44 Zusammenarbeit 4