Diese Transaktion dient zur Verwaltung von Systemparametern.

Die Transaktion ermöglicht über die Icons:

• Ändern der Systemparameter
• Drucken der Systemparameter

Die Änderungen der Systemparamater werden in den Dateien “TDPARA.INI” bzw. in “DNGPARA.INI” gespeichert.

Details sind bei den einzelnen Transaktions-Panelen beschrieben.

Auf diesem Panel können einzelne Nachrichtenkanäle zentral deaktiviert werden. Welche Nachrichtenkanäle in der Tabelle auf diesem Panel zur Verfügung stehen, ist in der Transaktion “Bearbeiten der Codetables” für die Tabelle CORTYP definiert.

Deaktiviert wird ein Nachrichtenkanal, indem in der Tabelle auf dem Panel “Nachrichten-Parameter” die Checkbox “Aktiv” nicht markiert wird. In der Bearbeitung von Geschäftstransaktionen hat dies zur Folge, dass keine Nachricht in dem deaktivierten Format mehr erzeugt werden kann. In den Stammdatem zum Beteiligten ist eine Authentisierung der deaktivierten Kanäle nicht möglich.

Autokonvertierung von Standby-L/C-Nachrichten :

• Die Freiformat-Nachricht für Standby-L/Cs kann in zwei verschiedenen Formaten/Strukturen erstellt werden.
• Das Format/die Struktur kann durch Auswahl einer der folgenden Optionen parametrisiert werden:
  • Freiformat Nachricht: Der Inhalt von Tag 79 der Freiformat-Nachricht entspricht dem brieflichen Äquivalent der jeweiligen Korrespondenz (z. B. der Änderungsmitteilung).
  • Ursprüngliche Nachrichtenstruktur: Der Inhalt von Tag79 der Nachricht entspricht dem früheren ursprünglichen SWIFT-Nachrichtenformat in einem getaggten Pretty Print Format, jedoch ohne Angabe der einzelnen Tag-Nummern.

Über das Panel “Brief-Layout” und weitere Transaktionen können eine Reihe von Einstellungen vorgenommen werden, die es ermöglichen, die ausgehende briefliche Korrespondenz in Schrift, Form und Layout an die Corporate Identity Vorgaben der Bank anzupassen.

Das Feld “Brief-Layout” sieht 2 mögliche Varianten vor:

In der Standarddefinition sind alle im Kopf-und Fussteil ausgegebenen Felder und Positionen festgelegt und können nicht verändert werden. Über den Button [Ansehen] (Vorschau der gewählten Einstellungen) kann ein Beispiel des Standard-Layouts angesehen werden. Die in der Standarddefinition ausgegebenen Elemente sind in Bezug auf Größe und Schriftart auf den Dokumentenstil / das Seitenlayout der Briefe (in der MyModelbank “a4.xsi”) abgestimmt. Diese Formatierungsvorgaben könnten jedoch geändert werden über die Transaktion “Verwalten von Dokumentenformatierungen”, die über den Button [Dok.-stil] gestartet werden kann. Hier kann das Seitenlayout der XSI-Dateien angepasst werden.

Diese Variante hat den Vorteil, dass es bereits ein vorgefertigtes Layout gibt, das sofort verwendet werden kann.

Um eine eigene Vorlage zu verwenden, muss in dem Feld “Brief-Layout” der Eintrag “Benutze Vorlage” ausgewählt werden. Es öffnen sich dann die Felder “Absenderangaben der Anwendung” und “Art der Vorlage”. In Feld “Art der Vorlage” gibt es die Möglichkeit, zwischen einer digitalen Vorlage und Briefpapier auszuwählen:

• Digital: Es kann ein eingescanntes Image verwendet werden, das zum Beispiel das bereits das Logo, die Fußzeile, Konzerndetails, Vorstand- und Aufsichtsrats-Angaben enthält. Dieses eingescannte Image kann sprachabhängig sein und muss je Sprache im Frame-Verzeichnis der Installation gespeichert werden. In dem Feld “Dateipfad der Vorlage” muss der Scan ausgewählt werden.
• Briefpapier: Es kann Briefpapier verwendet werden, das ähnlich dem eingescannten Image schon ein Logo enthalten kann.

Der Aufbau eines Briefes setzt sich in der Regel aus folgenden Teil-Elementen zusammen, für die entschieden werden kann, ob diese Elemente in Ihrem Brief-Layout ausgegeben werden sollen:

• Logo: Die Datei, die das Logo der Bank für das Standard-Layout (“Benutze Layout der Anwendung” wurde gewählt) enthält, wird je Entity in der Transaktion “Verwalten von Entities” in dem Feld “Logodatei in Briefen” eingetragen.

• Absenderangaben (Informationen zum Benutzer, der Benutzergruppe, der Filiale): In dem Feld “Absenderangaben der Anwendung” kann zwischen 2 Einstellungen gewählt werden: “Absenderangaben nicht benutzen” und “Vorlage und Absenderangaben benutzen”:
  • “Vorlage und Absenderangaben benutzen”: Der Block mit den Absenderangaben im Kopfteil des Briefes entspricht dem Standard-Layout der MyModelbank in Bezug auf die dort ausgegeben Felder und Positionen.
  • “Absenderangaben nicht benutzen”: Der Block mit den Absenderabgaben wird nicht ausgegeben. Es wird nur das Briefpapier bzw. die eingescannte Vorlage sowie der Seitenfuss des Standard-Layouts verwendet.
• Seitenformat: Das Seitenformat, also die Seitenhöhe- und Breite, die Grösse des Kopfteils, des Hauptteils und des Fussteils muss in der Transaktion “Verwalten von Dokumentenformatierungen” vorgenommen werden. Diese Transaktion kann über den Button [Dok.-stil] gestartet werden. Hier kann das Seitenlayout der XSI-Dateien angepasst werden. Die ausgehenden brieflichen Nachrichten in der MyModelbank verwenden die xsi-Datei “a4.xsi”. Wir empfehlen diese xsi-Datei anzupassen, statt eine neue zu definieren.

Über den Button [Ansehen] können die Auswirkungen sämtlicher Einstellungen überprüft werden.

Auf diesem Panel werden die Standardwerte definiert, die für die Abwicklung eines Auftrags verwendet werden, wenn in der Transaktion “Verwalten von Service Level Agreements” nichts anderes definiert ist.

Felder:

• Abwicklungszeit: Die von der Bank vorgegebene Zeit für die Verarbeitung, d.h. die Zeit, die ein Sachbearbeiter für die Erfassung benötigt.
• Freigabezeit: Die von der Bank vorgegebene Zeit, die ein Kontrolleur für die Freigabe benötigt.
• Mgr. Abwicklungszeit: Die Zeit, die die Manager für die technische Verarbeitung des Auftrags benötigen, d.h. bis die Services für die Freigabe (REL bzw. FIN ) erledigt sind.
• SLA Limit: Die maximale Dauer eines Auftrags, also konkret bis der Kunde Rückmeldung (i.d.R. in Form von Korrespondenz) zu seinem Auftrag bekommt. Der Inhalt des Feldes muss grösser sein als die Summe der Abwicklungszeit/ Freigabezeit und dem Mgr. Abwicklungszeit.
• Cut-Off Zeit: Der Zeitpunkt, zu dem der tägliche Abwicklungsschnitt gemacht wird. Das bedeutet alle Aufträge, die nach der definierten Cut-Off Zeit eingehen, stehen erst für den darauffolgenden Geschäftstag zur Verarbeitung an.
• Pufferzeit: Die “Pufferzeit” dient dazu, den Anwender möglichst frühzeitig über die mögliche Gefährdung einer SLA Vereinbarung zu informieren. Über das Feld wird definiert, wann ein Auftrag von Normal (“grün”) auf Warnung (“gelb”) umgeschaltet werden soll.
• Zeit je Termin: Die Verarbeitungszeit je Termin. Dieser Wert wird üblicherweise durch die jeweilige SLA Vereinbarung übersteuert.
• Order Workflow Zeit: Die Durchlaufzeit eines Auftrags durch den Pre-Order Workflow.
• SLA Tage: Ist dieser Wert > 0, wird zu Abwicklungszeit ein weiterer oder mehrere Tage hinzuaddiert. Erst an dem Tag, an dem die Abwicklungszeit abläuft, wird die Cut-off-Zeit berücksichtigt. Die Berechnung erfolgt exakt taggenau. Bei einem Tag werden also 1440 Minuten (24 Stunden * 60 Minuten) hinzugerechnet.

Bedeutung der Faktoren: In den Feldern “Pausiert”, “Korrektur” und “Manuell” kann ein “Faktor für die Berechnung der Durchlaufzeit” erfasst werden. Die Abwicklungszeit berechnet sich dann mit diesem Faktor.

Beispiel: Für die Abwicklungszeit sind 180 Minuten vorgegeben, unterbrochene Transaktionen werden mit einem Faktor von 50% berechnet, zu korrigierende Transaktionen mit einem Faktor von 10%. Wird die Erfassung einer Geschäftstransaktion pausiert, so wird eine Abwicklungszeit von nunmehr 90 Minuten für den SPT ermittelt, wird die Transaktion zur Korrektur geschickt eine Abwicklungszeit von 18 Minuten.

Auf diesem Panel kann für die Stammdatensysteme das 4 Augen Prinzip aktiviert oder deaktiviert werden.

Für kommende Standards-Releases kann das Aktivierungsdatum bzw. können die Aktivierungsdaten eingegeben werden. Zusätzlich werden hier, falls erforderlich, Aktivierungsdaten für andere Themen angegeben.

Die allgemeine Logik aller Felder besteht darin, als Datum das erste Datum einzutragen, ab dem neue Funktionen für jedes Thema aktiv werden sollen.

Produktionsumgebung:

• In einer produktiven Umgebung muss das Datum auf das offizielle Veröffentlichungsdatum gesetzt werden, das von der jeweiligen Community bekannt gegeben wurde.
• Bleibt das Feld für das Aktivierungsdatum leer, wird die Funktionalität von der Applikation automatisch zum “offiziellen” Veröffentlichungsdatum aktiviert.

Testumgebung:

• Um die Funktionalität zu testen, sollte das Datum auf ein beliebiges anderes Datum gesetzt werden.
• Frühere Funktionalitäten werden mit einem aktuellen Systemdatum vor dem Aktivierungsdatum getestet.
• Neue Funktionalitäten werden mit einem aktuellen Systemdatum ab oder nach dem Aktivierungsdatum getestet.

Swift Standard Releases SR20xx Aktivierung am:

• Dies bezieht sich auf die jährlichen Swift Interbank Standard Releases für MT-Nachrichten.
• Falls es keine Änderungen für die von dieser Anwendung unterstützten Nachrichten gibt, ist diese Option nicht sichtbar.
• Wenn ein Aktivierungsdatum eingegeben wird, wird die neue Logik für die Swift MT Interbank-Nachrichten aktiviert.
• Wenn andere Korrespondenzkanäle (wie SWIFT Score, Bolero, DTA usw.) ebenfalls von den “Interbank”-Änderungen betroffen sind, werden mit diesem Aktivierungsdatum auch die entsprechenden Änderungen in diesen Kanälen aktiviert.

Swift CBPR+ Aktivierung am:

• Swift Interbank-Zahlungsnachrichten werden standardmäßig als Swift MT-Nachrichten generiert.
  
• Wenn aktiviert, werden Swift-Zahlungsnachrichten ab dem angegebenen Datum als MX-Nachrichten in XML generiert.
• MT-Zahlungsnachrichten und MX-Zahlungsnachrichten (CBPR+) können von dieser Anwendung nicht parallel erzeugt werden.
• Für die Produktion: Die DOKA-NG verwendende Bank kann sich für eine Aktivierung zu einem beliebigen Datum zwischen dem 20. März 2023 und 20. November 2025 entscheiden, um von MT- auf MX-Zahlungen umzustellen.
• Das späteste Aktivierungsdatum für MX-Zahlungen (CBPR+) ist Sonntag, 23. November 2025.

T2 RTGS Aktivierung am:

• Das Target2-System ersetzt seine bestehenden Funktionen durch einen “Big Bang” und benennt sich in “T2 RTGS” um.
• Vor dem Aktivierungsdatum werden Target2-Zahlungsnachrichten in einem speziellen Target2-MT-Format erstellt.
• Nach dem Aktivierungsdatum werden T2 RTGS-Zahlungsnachrichten im neuen XML-Format erstellt.
• Das Aktivierungsdatum für T2-RTGS-Zahlungsnachrichten muss Montag, 20. März 2023 sein.

SIC-Aktivierung am:

• Dient zur Aktivierung der neuesten Version für SIC- und euroSIC-Zahlungsmeldungen (pacs.008 und pacs.009).
• Dies kann derzeit nur von Banken genutzt werden, die den Schweizer Franken 'CHF' als Basiswährung in der Applikation eingestellt haben.
• Das Aktivierungsdatum für SIC/euroSIC-Zahlungen ist Sonntag, 20. November 2022.

Swift Autokonvertierung zu MT759:

• Für Briefe, für die es keinen eigenen SWIFT-Nachrichtentyp der Kategorie 7 (MT7xx) gibt, verwendet DOKA-NG die Autokonvertierung auf MT799.
• Basierend auf der SWIFT-Empfehlung sollte MT759 anstelle von MT799 verwendet werden und die Verwendung von MT799 soll reduziert werden.
• Wenn die Checkbox “Swift Autoconvert to MT759” aktiviert ist, werden die Nachrichten automatisch in MT759 anstelle von MT799 konvertiert.

Auf diesem Panel kann definiert werden, welche Felder der Applikation von einer Embargo-Anwendung geprüft werden sollen. Weitere Information sind unter Compliance zu finden.

Systemeinstellungen
Nachrichten-Parameter
Brief-Layout
Referenznummern
Service Level Agreement
Stammdaten
Swift Release Aktivierung
E-Mail Einstellungen
Embargo