User Tools
Add this page to your book 
Remove this page from your book 
Manage book (
Help Nachteilige Änderungen
Hantierung von Änderungen, die einer Bestätigung durch die Gegenseite bedürfen.
Wenn ein Kontrakt (z.B. ein Import-Akkreditiv) zum Nachteil des Begünstigten geändert werden soll, dann muss der Begünstigte dieser Änderung zustimmen, sonst ist diese Änderung nicht wirksam. Änderungen, die zu dieser Kategorie gehören sind z.B. Betragsreduzierungen, Laufzeitverkürzungen oder Veränderungen der Warenbeschreibung, die eine bessere Qualität oder schärfere/zusätzliche Prüfungen beschreiben. Üblicherweise wird die Auslandsbank die Änderungsanfrage an den Begünstigten weiterleiten, aber nicht aktiv dafür sorgen, dass auch wirklich eine Bestätigung zurückkommt. Der Begünstigte hat die Änderung i.d.R. vorher bereits mit dem Importeur abgestimmt und hat somit auch keinen Grund nochmals eine Bestätigung loszuschicken, sodass i.d.R. keine Bestätigung zurückkommt. Nach den derzeit gültigen einheitlichen Richtlinien sind für derartige Rückbestätigungen von Änderungen auch keine Fristen gesetzt, sodass i.d.R. erst mit der nächsten Vorlage von Dokumenten eine implizite Zustimmung zu der Änderung erkennbar wird.
Um diesen Sachverhalt noch zu verkomplizieren können auch nach einer zu bestätigenden Änderungsanforderung weitere Änderungswünsche gestellt werden, jeweils bevor die explizite oder implizite Bestätigung der Gegenseite eingegangen ist.
Das große Problem bei derartigen Änderungen ist, das der zugrunde liegende Vertrag erst nach der erteilten Rückbestätigung verändert werden darf. Daher sollten die Banksachbearbeiter bei jeder weiteren Bearbeitung dieses Kontraktes darauf hingewiesen werden, dass noch unbestätigte Änderungsanforderungen vorhanden sind.
Im Rahmen einer Änderungsanforderung lassen sich die normalerweise eingehenden Informationen in zwei große Bereiche aufteilen. Einerseits feldweise direkt zuordbare und automatisch verarbeitbare Informationen, wie Betragsänderung oder neue Laufzeiten. Diese Informationen werden via SWIFT in separaten Fieldtags transportiert und sind daher auch i.d.R. automatisiert verarbeitbar. Andererseits gibt es unstrukturierte Freitext-Informationen, die in einem SWIFT-Fieldtag in Klartext beschreiben, was sich an dem Kontrakt ändern soll. Diese Freitext-Informationen können beliebige Informationen enthalten wie z.B. Angaben zum Ersetzen bestimmter Absätze in der Warenbeschreibung oder zusätzliche Bedingungen. Wie diese Freitext-Informationen in den zugrunde liegenden Kontrakt eingearbeitet werden, ist bei auf Bestätigung wartenden Kontrakten ein nicht lösbares Problem, da der Basiskontrakt, in den diese Texte eingearbeitet werden sollen, nicht eindeutig klar ist.
Um in derartigen Situationen eine formal korrekte Darstellung zu ermöglichen, die auch im Zurückweisungsfall sauber und problemfrei hantiert werden kann, ist in der Applikation folgendes Lösungskonzept implementiert.
1. Änderungen, die keiner Bestätigung durch die Gegenseite bedürfen und die eingehen, wenn nicht auf eine Bestätigung gewartet wird, werden in den Änderungstransaktionen (xxxAME-Transaktionen) verarbeitet. Dabei werden die entsprechenden Betrags-, Engagement- und Textänderungen im Kontrakt vorgenommen und der neue Zustand sofort festgeschrieben.
2. Änderungen, die einer Bestätigung bedürfen oder normale Änderungen, die verarbeitet werden sollen, wenn auf eine Bestätigung durch die Gegenseite gewartet wird, werden über die Änderungsanforderung-Transaktionen (xxxRAM-Transaktionen) verarbeitet, die eine entsprechende xxxAME-Transaktion registriert.
3. Bei jeder weiteren Bearbeitung unter einem Kontrakt, der auf eine Gegenbestätigung wartet (wo eine noch nicht abgeschlossene xxxRAM-Transaktion offen ist), wird der Benutzer darauf hingewiesen, dass eine unbestätigte Änderungsanforderung vorliegt.
4. Falls z.B. bei einer Dokumenteneinreichung die implizite Bestätigung oder Ablehnung der Änderungsanforderung erkennbar ist, kann der Sachbearbeiter durch Aufgreifen der wartenden xxxAME-Transaktion sehr schnell die wirkliche Änderung vorab komplett durchführen bzw. die Ablehnung der Änderungsanforderung mit einer freien Nachricht zurückmelden. Anschließend wird die eigentlich derzeit anliegende Transaktion (in diesem Fall die Dokumenteneinreichung) durchgeführt.
4.1. Bei einer Bestätigung werden sowohl die strukturierten Datenfelder als auch der eine unstrukturierte Freitext der ursprünglichen Änderungsanforderung in die entsprechenden Felder der xxxAME-Transaktion gestellt. Damit werden die strukturierten Änderungsinformationen automatisch in den entsprechenden Zielfeldern fortgeschrieben. Die ggf. notwendige Verteilung der Freitext-Informationen in die entsprechenden Textfelder für die Warenbeschreibung, die Dokumente, etc. wird allerdings erst jetzt in der Abwicklung der xxxAME-Transaktion vorgenommen, da erst jetzt der zugrunde liegende Basiszustand sicher klar ist.
4.2. Im Falle der Ablehnung muss statt der registrierten xxxAME- eine Freie Nachricht-Transaktion (xxxFRE-Transaktion) abgewickelt werden. Dies kann durch Re-Routing der Registrierung auf xxxFRE und anschließendem Aufgreifen der Registrierung oder durch manuelles Aufrufen der xxxFRE-Transaktion und manuelles Löschen der Registrierung geschehen.
4.3. Im Falle einer eingehenden elektronischen Nachricht, in der der Begünstigte seine Zustimmung/ Ablehnung avisiert, kann die Nachricht in SPTROU an xxTFRE (im Falle einer Ablehnung) oder an xxTATT (im Falle einer Akzeptierung) gerouted werden, um die Nachricht dauerhaft in der Applikation zu speichern. Anschließend kann der Benutzer die Autoregistrierung für die xxTAME Transaktion aufgreifen und die Änderung abwickeln. Im Falle einer Ablehnung kann in der gerouteten xxTFRE Transaktion eine freie Nachricht erzeugt werden und die registrierte xxTAME gelöscht werden. Wenn an die Transaktion LxTFRE gerouted wird, wird der Nachrichtentyp mit 'Empfangsbestätigung' vorgeschlagen und eine MT730 (oder eine entsprechende briefliche Nachricht) wird mit dem Codewort /BENREJ/ im Feld 72 vorbelegt.
5. Bei den im Rahmen einer Änderung (via xxxAME oder xxxRAM) versandten Änderungsnachrichten kann, so es im Rahmen der jeweiligen Installation gewünscht wird, leicht auf die Existenz von noch offenen Änderungsanfragen hingewiesen werden. Der zugrunde liegende Kontrakt ist allerdings noch nicht fortgeschrieben. D.h. weder die Beträge oder Datumsfelder sind geändert, noch sind die gewünschten textuellen Änderungen in den Kontrakt eingearbeitet.
6. Daraus ergibt sich dann auch, dass jede Änderungsanfrage, auch wenn sie abgelehnt wird, in der Applikation gezählt wird und eine Änderungsnummer zugeteilt bekommt. Der Arbeitsaufwand und die Hantierung einer Änderung ist angefallen, auch wenn der Änderungsauftrag von der Gegenseite zurückgewiesen wurde.
Das bedeutet also, dass die eigentliche Arbeit eine komplexe Änderung in ein Akkreditiv einzuarbeiten eben nicht beim Eingang der Änderung erfolgt, sondern dass das Einarbeiten insbesondere in die Texte erst bei der wirklichen Akzeptierung der Änderung erfolgt. Ein wichtiger Nebeneffekt dieses Vorgehens ist, dass, auch wenn mehrere Änderungen unterwegs sind und nicht alle akzeptiert, sondern auch teilweise abgelehnt werden, jede einzelne akzeptiert werden kann und für sich in sich geschlossen den Kontrakt dann fortschreibt und die Fortschreibung des Kontraktes auch nachvollziehbar und klar bleibt. Es werden auch nicht in zwischendurch erstellten Nachrichten noch nicht akzeptierte (und evtl. anschließend zurückgewiesene) also niemals gültige Zahlen oder Texte ausgewiesen.
Dabei muss allerdings bedacht werden, dass, solange offene xxxRAM-Anfragen vorhanden sind, in externer Korrespondenz auf die offenen Änderungen hingewiesen wird.
Nachteilige Änderungen in Zusammenhang mit Transfer L/C's oder Back-to-Back L/C
Wenn ein vorhandenes Export Akkreditiv mit einem übertragbaren Akkreditiv oder einem Back-To-Back Akkreditiv verknüpft ist, kann die Änderung des Master L/C auch eine Änderung des Transfer L/C oder Back-To_Back L/C notwendig machen.
Dies wird in der Applikation wie folgt unterstützt:
Jegliche Änderung an den Kontaktbeträgen wird absichtlich nicht in das Transfer L/C oder Back-To-Back L/C kopiert. Wenn eine Auto-Registrierung aufgegriffen wird, werden Betragsänderungen am Hauptkontrakt in den “nicht zugeordneten Felder” aufgelistet und können durch den Sachbearbeiter kopiert werden.
