Name | Hilfetext-Beschreibung | Datentyp | Länge | Codetable |
---|---|---|---|---|
INR | Interne eindeutige ID | Text | 8 | |
OWNREF | Eigene Referenz | Text | 16 | |
NAM | Name | Text | 80 | |
OPNTRNINR | TRNINR der Eröffnungstransaktion | Text | 8 | |
CREDAT | Erstellungsdatum | Datum | 12 | |
ISSREF | L/C-Nummer | Text | 16 | |
AMEDAT | Datum der letzten Änderung | Datum | 12 | |
AMENBR | Anzahl der Änderungen | Numerisch | 3 | |
AVBWTH | Benutzbar bei | Text | 1 | AVBWTH |
AVBBY | Benutzbar durch | Text | 1 | AVBBY0 |
CLSDAT | Schließungsdatum | Datum | 12 | |
CNFSTA |
Dieses Feld enthält den Bestätigungsstatus des Rembourskontraktes.
Dieses Feld enthält das Verfallsdatum des Akkreditivs, für das die Remboursermächtigung erteilt wurde an und zeigt daher das späteste Vorlagedatum der Dokumente unter dem Akkreditiv an.
Dieses Feld enthält den Ort des Verfalls des Akkreditivs für den die Remboursermächtigung erteilt wurde. Der Ort des Verfalls ist fest mit dem Verfallsdatum verbunden, da es den Ort, an dem die Dokumente unter dem Akkreditiv vorgelegt werden müssen, detaillierter beschreibt.
Dieses Feld definiert den Kontraktbetrag näher und ist bei der Prüfung der vorgelegten Dokumente unter dem Kontrakt von Bedeutung. Wird der Code “not exceeding” verwendet, ist keine Betragstoleranz erlaubt. Wird der Code “Gemäß ERA” verwendet, gelten die Regeln unter Artikel 30 der ERA.
Code | Text |
---|---|
N | NOT EXCEEDING |
X | Gemäß ERA |
Dieses Feld bezeichnet die Positivtoleranz bezogen auf den Nominalbetrag des zugrundeliegenden Kontrakts als Prozentsatz zuzüglich zum Nominalbetrag. Zur Berechnung des Maximumbetrags des Kontrakts (z.B. das max. Risiko der Bank) wird der positive Toleranzbetrag dem Nominalbetrag hinzuaddiert.
Dieses Feld bezeichnet die Negativtoleranz bezogen auf den Nominalbetrag des zugrundeliegenden Kontrakts als Prozentsatz, der vom Nominalbetrag abzuziehen ist.
Dieses Feld enthält das Eröffnungsdatum eines Kontrakts. Ist das Feld gefüllt, wurde der Kontrakt rechtskräftig eröffnet und kann für Geschäftstransaktionen verwendet werden. Das Datum beschreibt den Zeitpunkt, an dem der Kontrakt rechtskräftig wurde. Es kann ein Datum vor dem Erstellungsdatum sein, wenn der Kontrakt rechtskräftig war, bevor er in der Datenbank gespeichert wurde.
Dieses Feld enthält die Benutzer-ID des Sachbearbeiters, der für die Bearbeitung dieses Kontrakts verantwortlich ist.
Dieses Feld enthält die Anzahl der Remboursabforderungen, die unter diesem Kontrakt eingegangen sind. Mit jeder neue Inanspruchnahme wird die Anzahl um einen erhöht und nie mehr reduziert.
Dieses Feld enthält den Versionszähler, um die Versionshistorie eines Eintrags dieser Tabelle verfolgen zu können. Die einzelnen Versionen werden über Einträge in der SLG-Tabelle hantiert.
Dieses Feld enthält Informationen, wer die unter der Remboursermächtigung anfallenden Gebühren zahlt.
Dieses Feld gibt an, ob die Remboursermächtigung der aktuellsten Version der Uniform Rules for Bank-to-Bank Reimbursements under documentary credits, International Chamber of Commerce, Paris, France, unterliegt. Diese Richtlinien treten ab dem Ausgabedatum in Kraft.
In diesem Feld kann ausgewählt werden, ob die Bestätigung des Rembourskontraktes von der eröffnenden Bank oder der abfordernden Bank angefordert wurde.
Kontraktstatus-Flag. Falls gesetzt, ist der Kontrakt reserviert, d.h. es müssen nur einige Basisfelder gefüllt sein. Sichtbar in “Voravis einer Remboursermächtigung” (RMTPOP) und “Info Remboursermächtigung” (INFRMD). Unsichtbar in allen anderen Transaktionen.
Code | Text |
---|---|
Normaler Kontrakt | |
X | Reservierter Kontrakt |
Dieses Feld enthält den Warencode der verschifften Waren. Der Warencode wird benutzt, um Auswertungen für bestimmte Warengruppen zu ermöglichen. Die Codetable kann entsprechend den Anforderungen der Bank angepasst werden.
Dieses Feld zählt die offenen (nicht geschlossenen) Inanspruchnahmen unter der Remboursermächtigung. Mit Erhalt einer Remboursabforderung wird die Anzahl automatisch um eine erhöht. Wird die Remboursabforderung gezahlt oder unbezahlt geschlossen, wird die Anzahl der offenen Inanspruchnahmen um eine reduziert.
Dieses Feld enthält das Risikoland des Rembourskontraktes. Es wird für statistische Zwecke verwendet und ermöglich der Remboursbank das Länderrisiko zu bewerten, das durch den Rembourskontrakt entstanden sein kann.
Dieses (unsichtbare) Feld legt fest, ob der Betrag oder der Prozentsatz in einem teilweise bestätigten Kontrakt bestätigt wird.
Basierend auf dieser Information werden Prozentsatz oder Betrag geschützt und über das andere Feld berechnet.
Code | Text |
---|---|
A | Betrag bestätigt |
P | Prozent bestätigt |
Nicht bestätigt |
Über dieses Feld werden die Richtlinien spezifiziert, denen die Remboursermächtigung unterliegt.
Code | Text |
---|---|
URR LATEST VERSION | ERR AKTUELLE VERSION |
NOTURR | UNTERLIEGT NICHT ERR |
Verfalldatum der eigenen Remboursverpflichtung (Bestätigung)
Dieses Flag wird in einer (vor)eröffnenden Transaktion gesetzt, sofern eine eingehende Nachricht sofort abgelehnt wird. Der Kontrakt wird sofort geschlossen.
Dieses Feld enthält den externen Schlüssel der Entity, zu der diese Daten gehören.
Dieses Feld wird automatisch während der Eingabe gefüllt und wird als Filter beim Zugriff auf die Datenbank verwendet. Ohne spezielle Implementierung sind für den Benutzer nur Einträge der aktuell aktiven Entity sichtbar.
Dieses Feld enthält den Prozentsatz einer teilbestätigten Remboursverpflichtung. Das Feld ist nur dann für Einträge offen, wenn das Akkreditiv durch die die Applikation verwendende Bank bestätigt ist.
Dieses Feld wird automatisch beim Buchen von Bardeckung auf einem Deckungskonto unter einem Rembours gesetzt.
Erste Version zur Unterstützung der Differenzierung vordefinierter Bankprodukte über Geschäftsfelder hinweg. Diese organisatorische Lösung besteht aus drei Feldern PRDCOD, PRDSUB und PRDVAR, die ein Bankprodukt, eine Unterdifferenzierung und bei Bedarf individuelle Varianten bereitstellen. Hier identifiziert das PRDCOD den Geschäftsbereich zusammen mit einigen Schlüsselkriterien wie bestätigtem oder nicht bestätigtem LC in einer branchenübergreifenden eindeutigen Identifizierung.
Erste Version zur Unterstützung der Differenzierung vordefinierter Bankprodukte über Geschäftsfelder hinweg. Diese organisatorische Lösung besteht aus drei Feldern PRDCOD, PRDSUB und PRDVAR, die ein Bankprodukt, eine Unterdifferenzierung und bei Bedarf individuelle Varianten bereitstellen. Hier identifiziert der PRDSUB die geschäftssektorspezifischen bankseitigen definierten Produkte und fügt einige wichtige Unterkriterien in einer branchenübergreifenden eindeutigen Identifizierung hinzu.
Erste Version zur Unterstützung der Differenzierung vordefinierter Bankprodukte über Geschäftsfelder hinweg. Diese organisatorische Lösung besteht aus drei Feldern PRDCOD, PRDSUB und PRDVAR, die ein Bankprodukt, eine Unterdifferenzierung und bei Bedarf individuelle Varianten bereitstellen. Hier ist die Produktvariante als mögliche Erweiterung zur Einrichtung spezifischer Varianten unterhalb des Produkt- und Unterproduktcodes vorgesehen.