Das Abrechnung-Details Panel ist ein dem eigentlichen Abrechnung-Panel vorgeschaltetes Panel. Auf diesem Panel können Einstellungen vorgenommen werden, die nur für die jeweilige Transaktion gelten (wie zum Beispiel die Erfassung eines Abrechnungsbetrages) oder Einstellungen, die für sämtliche Transaktionen des Kontraktes gelten (zum Beispiel Abrechnungsdefinitionen der Kontraktbeteiligten).
Kundenabzugsbetrag
Auf diesem Panel kann ein Kundenabzugsbetrag eingegeben werden, um den der abzurechnende Betrag reduziert wird. Das Ergebnis dieser Berechnung wird in dem Feld “Reduzierter Abrechnungsbetrag” ausgewiesen. Verwendet wird dieses Feld meist bei Abrechnung eines Dokumentensatzes unter einem Akkreditiv oder einem Inkasso. Haben sich die Vertragsparteien geeinigt, dass die Dokumente gegen Gewährung eines Diskonts aufgenommen werden, wird der verhandelte Rabattbetrag als Kundenabzugsbetrag in der Abrechnung eingetragen und reduziert somit den Dokumentenbetrag. In Transaktionen, die lediglich die Abrechnung von Gebühren vorsehen und demnach über keinen Abrechnungsbetrag verfügen, ist das Feld deaktiviert und damit nicht eingebbar. Ob das Feld Kundenabzugsbetrag aktiviert oder deaktiviert ist, wird über einen Eintrag in der Transaktion “Verwalten von Entity Gruppen Transaktions-Profilen” (DBxETP) oder eine entsprechend programmierte Regel in der Source definiert.
Tabelle “Abrechnungsdefinition der Beteiligten”
In dieser Tabelle kann für jeden Kontraktbeteiligten definiert werden:
Für alle diese Tabelleneinträge ist es unerheblich, ob der Benutzer diese Informationen bereits bei Kontraktanlage oder erst mit der Abrechnung hinterlegt.
Für das Kontodefaulting wird pro Rolle zunächst nach einer direkten Kontoverbindung in Kontraktwährung gesucht. Gibt es dieses nicht, wird nach einem Konto in Kursbasis-Währung gesucht, gibt es auch da keines, nach einem anderen verfügbaren Konto. Erst wenn es keine direkte Kontobeziehung gibt, wird als Disposition PAx (Deckungsanforderung/Belastungsermächtigung) vorgeschlagen. Die vorgeschlagenen Werte können vom Benutzer geändert werden.
Ausnahme: Wurde unter einem Import Akkreditiv eine Remboursermächtigung erteilt, so erfolgt die Zahlung bei Dokumentenabrechnung über die Remboursbank und die Einstellungen im Settlement Details werden nicht beachtet (d.h. es findet keine automatische Konvertierung statt, auch wenn die Remboursbank eine direkte Kontoverbindung bei der die Applikation verwendenden Bank unterhält).
In dem Feld “Kurs neu bewerten am” kann ein Ausführungsdatum für den Service “Kurs Neubewertung” (PDX) eingegeben werden. Ist ein Datum eingegeben, so wird der Service PDX erst nach Erreichen des eingegebenen Datums ausgeführt.
Die Währungen und Konten werden bei jeder weiteren Abrechnung unter diesem Kontrakt berücksichtigt.
In dem unteren Grid werden die Kurse vorgeschlagen, mit denen die Abrechnung für die jeweilige Rolle erfolgen soll.
Das Panel “Abrechnung” bietet einen Überblick über alle abrechnungsrelevanten Informationen zu der ausgewählten Transaktion.
Diese sind im Einzelnen:
Abhängig vom gewählten Dispositions-Code in Tabelle 3, werden für die ausgehende Zahlung automatisch die benötigten Zahlungsnachrichten erzeugt.
Die hier eingebbaren Beträge können außerhalb des Kontrakts einem Kostenträger belastet und einem Empfänger gutgeschrieben/überwiesen werden. Hierbei fungiert die Bank als Korrespondent für die beiden Beteiligten, die bei dem betreffenden Geschäft vorhanden sein müssen.
Spalte | Beschreibung |
---|---|
1 | Zahler (Zahlungspflichtiger) - legt fest, wer den Betrag zu zahlen hat |
2 | Empfänger - legt fest, an wen zu zahlen ist |
3 | Quelle - zeigt an, woher die vorgeschlagene Gebühr kommt * P = Gebührenpool (eine aus dem Gebührenpool geladene Gebühr) * U = Benutzer (eine vom Benutzer in dieser Transaktion manuell erfasste Gebühr) * D = Bereits avisiert (eine bereits avisierte Gebühr, die neu aus dem Pool geladen wird) |
4 | Disp. - disponiert die weitere Handhabung der Gebühren * X = jetzt abrechnen Diese Auswahl ist für alle endgültigen Abrechnungen verfügbar, die Gebühren werden in den Nachrichten ausgewiesen. * P = im Gebührenpool speichern Diese Auswahl sorgt dafür, dass die Gebühren nur intern im Gebührenpool gespeichert werden und damit zu einem späteren Zeitpunkt abgerechnet werden. Diese Gebühren werden nicht in den Nachrichten ausgewiesen. Beim Start einer weiteren Transaktion werden diese Gebühren aus dem Pool geladen und in die Abrechnungsmaske eingestellt. * V = Avisieren von Gebühren Diese Gebühren werden ebenfalls im Gebührenpool gespeichert, darüberhinaus aber auch in den Nachrichten ausgewiesen. * D = bereits avisierte Gebühren Ist als Eingabe nicht erlaubt und wird nur angezeigt, wenn eine bereits avisierte Gebühr neu aus dem Pool geladen wird (Quelle = “Bereits avisiert” (D)), damit der Benutzer erkennen kann, dass diese Gebühren bereits in einer vorangegangenen Transaktion in den Nachrichten ausgewiesen wurden. In diesem Fall kann die Gebührenzeile (abgesehen von der Disposition) nicht mehr geändert werden, auch die Felder auf dem Details Panel zu der Gebühr sind für Benutzereingaben gesperrt. Mit dem Minus-Zeichen in der rechten oberen Ecke der Tabelle kann die bereits avisierte Gebühr logisch gelöscht werden. Der Betrag wird dann auf “0” gesetzt und es wird zur Information des Erfassers und des Kontrolleurs eine Warnung eingestellt. * S = vorläufig abrechnen Diese Auswahl ist nur verfügbar, wenn als Abrechnungstyp “temporär” gewählt wurde, die Gebühren werden in den Nachrichten ausgewiesen, es erfolgt aber keine Buchung. |
5 | Text für Zahler - Angaben über die Kosten sind einzugeben |
6 | Text für Empfänger - Angaben über die Zahlung sind einzugeben |
7 | Währung - ist manuell zu wählen, vorgeschlagen wird die Kontraktwährung |
8 | Betrag - ist manuell einzugeben oder kann berechnet werden |
9 | Icon ![]() |
Der mittlere Teil des Panels listet die bankeigenen Gebühren in einer Tabelle auf. Überwacht durch Prüffelder in jeder Zeile, können Gebühren direkt abgerechnet oder in den Gebührenpool für spätere Abrechnungen eingestellt werden. Gebühren, die aus vorangegangenen Transaktionen bereits im Gebührenpool liegen, werden zur Abrechnung in nachfolgenden Transaktionen vorgeschlagen. Wird eine in den Pool gestellte Gebühr geändert, so wird diese geänderte Gebühr mit der Transaktion gespeichert.
Spalte | Beschreibung |
---|---|
1 | Rolle - Kostenträger der Gebühr. Die Bezeichnung der Rolle wurde aus Platzgründen abgekürzt und ist als dreistelliges Rollenkürzel sichtbar. Wenn der Cursor für einen Moment auf dem Rollenkürzel verweilt, wird der Langtext des Rollenkürzels und der in der Transaktion dazugehörige Beteiligte in Form eines Hinweis (“Hint”) angezeigt. |
2 | Code - Gebührencode Alle in dieser Transaktion verfügbaren Gebührencodes werden angezeigt. Wenn der Cursor für einen Moment auf dem Gebührencode verweilt, wird der Langtext der Gebühr in Form eines Hinweis (“Hint”) angezeigt. Beim Öffnen der Combobox wird neben den Codes der dazugehörige Langtext angezeigt. In den Stammdaten zu den Gebühren (Transaktion Icon ![]() ![]() |
3 | (Gebühren-)Quelle - zeigt an, woher die vorgeschlagene Gebühr kommt * T = Transaktion (eine Gebühr, die in dieser Transaktion zur Abrechnung von der Applikation vorgeschlagen wird. Für die so vorgeschlagenen Gebühren gibt es einen Gebühreneintrag in der Transaktion “Verwalten von Transaktionskonfigurationen” (DBIATC) oder eine entsprechend programmierte Regel in der Source. * P = Gebührenpool (eine aus dem Gebührenpool geladene Gebühr) * U= Benutzer (eine vom Benutzer in dieser Transaktion manuell erfasste Gebühr) * D= Bereits avisiert (eine bereits avisierte Gebühr, die neu aus dem Pool geladen wird) |
4 | Disp. - disponiert die weitere Handhabung der eigenen Kommissionen/ Gebühren * X = jetzt abrechnen Diese Auswahl ist für alle endgültigen Abrechnungen verfügbar, die Gebühren werden in den Nachrichten ausgewiesen. * P = im Gebührenpool speichern Diese Auswahl sorgt dafür, dass die Gebühren nur intern im Gebührenpool gespeichert werden und damit zu einem späteren Zeitpunkt abgerechnet werden. Diese Gebühren werden nicht in den Nachrichten ausgewiesen. Beim Start einer weiteren Transaktion werden diese Gebühren aus dem Pool geladen und in die Abrechnungsmaske eingestellt. * V = Avisieren von Gebühren Diese Gebühren werden ebenfalls im Gebührenpool gespeichert, darüberhinaus aber auch in den Nachrichten ausgewiesen. * D = bereits avisierte Gebühren Ist als Eingabe nicht erlaubt und wird nur angezeigt, wenn eine bereits avisierte Gebühr neu aus dem Pool geladen wird (Quelle = “Bereits avisiert” (D)), damit der Benutzer erkennen kann, dass diese Gebühren bereits in einer vorangegangenen Transaktion in den Nachrichten ausgewiesen wurden. In diesem Fall kann die Gebührenzeile (abgesehen von der Disposition) nicht mehr geändert werden, auch die Felder auf dem Details Panel zu der Gebühr sind für Benutzereingaben gesperrt. Mit dem Minus-Zeichen in der rechten oberen Ecke der Tabelle kann die bereits avisierte Gebühr logisch gelöscht werden. Der Betrag wird dann auf “0” gesetzt und es wird zur Information des Erfassers und des Kontrolleurs eine Warnung eingestellt. * S = vorläufig abrechnen Diese Auswahl ist nur verfügbar, wenn als Abrechnungstyp “temporär” gewählt wurde, die Gebühren werden in den Nachrichten ausgewiesen, es erfolgt aber keine Buchung. |
5 | Einheiten - zeigt die Anzahl der berechneten Einheiten an. Eine Einheit kann z.B. eine Stückzahl sein oder bei einer Zinsberechnung auch die Anzahl Zinstage. |
6 | Langer Gebührentext - zeigt den Gebührentext gemäß Definition der Gebühren in den Stammdaten (Transaktion “Verwalten von Gebühren”) an. Der Gebührenlangtext kann je nach Definition in den Stammdaten geändert werden. |
7 | Währung - Von der Applikation wird die Kontraktwährung vorgeschlagen, es sei denn, für die Rolle ist eine abweichenden Gebührenwährung hinterlegt worden. Eine abweichende Gebührenwährung kann je im Kontrakt vorhandenen Beteiligten (Rolle) auf dem Abrechnungs-Details-Panel eingetragen werden |
8 | Betrag - je nach Gebührenart (Provisionen, feste Gebühren) wird der zu zahlende Betrag errechnet bzw. ist einzugeben. Bei Rückvergütungen ist ein Minuszeichen dem Betrag voran zu stellen. |
9 | Icon ![]() |
Der untere Teil des Panels summiert die in der Transaktion abzurechnenden Beträge für jeden Beteiligten. Die aufgeführten Beträge resultieren aus den Beträgen der ersten beiden Tabellen, des Abrechnungsbetrages sowie bei einigen Transaktionen auch aus Eingaben auf anderen Panelen (beispielsweise Bardeckungsbuchungen). Die Berechnung der Beträge ist in der Transaktion festgelegt. Weiterhin sind die Währung und die Art der Zahlung für Belastung/Gutschrift definiert.
Spalte | Beschreibung |
---|---|
1 | Zeigt an, ob ein Abrechnungsbetrag gesplittet wurde. Wenn kein Splitting vorgenommen wurde, ist ein “-” in der Spalte eingetragen. Dies ist der Normalfall. Weitere Information dazu finden Sie im Abschnitt Splitten von Beträgen. |
2 | Rolle - enthält das Kürzel des entsprechenden Beteiligten. Die Bezeichnung der Rolle wurde aus Platzgründen abgekürzt und ist als dreistelliges Rollenkürzel sichtbar. Wenn der Cursor für einen Moment auf dem Rollenkürzel verweilt, wird der Langtext des Rollenkürzels und der in der Transaktion dazugehörige Beteiligte in Form eines Hinweis (“Hint”) angezeigt. |
3 | in - Währung für Belastung/Gutschrift (Zielwährung) |
4 | Gez. Betrag - enthält den Gegenwert in der Zielwährung, berechnet mit dem eingegebenen/gespeicherten Umrechnungskurs. Dieser wird über den Button Details eingegeben, bzw. von der Applikation vorgeschlagen. |
5 | Disp - Enthält den Dispositions-Code für diese Zeile, wobei der Buchstabe “D” am Ende eine Belastungsbuchung (Debit), der Buchstabe “C” eine Gutschrift (Credit) bedeutet. * DAD/ DAC - direkte Kontoverbindung * PAD/ PAC - Deckungsanforderung/ Belastungsermächtigung * IND/INC - (interne) Buchung auf ein Zwischenkonto * HLD/ HLC - Bardeckungskonto (die Buchung erfolgt auf einem internen Cash Cover-Konto für Bardeckungs-Beträge) * IBD/IBC - Filialverrechnung Belastung/Gutschrift * BRF - offene Zahlungen * BEF - offene Zahlungen * TRF - Importfinanzierung * HLD - Bardeckungskonto * FND/FNC Lastschrift/Zurückzahlung * TGC - Targetzahlung * IZD/IZC - IZV Belastung/Gutschrift * SIC - SIC/EuroSic Zahlung * SPD/SPC - Sepa Belastung/Gutschrift * Weitere Dispositions-Codes, wie z.B. Dispositionscodes des lokalen Clearing Systems sind je nach Transaktion und Datenkonstellation möglich |
6 | Konto - Enthält das zur vorgeschlagenen/ ausgewählten Disposition passende Konto, sofern ein eindeutiges Konto in den Stammdaten verfügbar ist. Disposition und Konto sind abhängig vom sogenannten Kontendefaulting. Darin wird definiert, welche Konten und Dispositionstypen vorgeschlagen werden. Wird in den Stammdaten z.B. für die gewählte Zielwährung ein Kontokorrentkonto gefunden, würde die Disposition DAD/ DAC vorgeschlagen werden. Gibt es in der gewählten Zielwährung kein direktes Konto, dafür aber ein Nostrokonto würde die Disposition PAD/ PAC vorgeschlagen werden. Ist für die gewählte Zielwährung weder ein Loro noch ein Nostrokonto hinterlegt, besteht für den Benutzer die Möglichkeit, ein internes Konto (IND/ INC) zu bebuchen. |
7 | Valuta - Vorgeschlagen wird das Tagesdatum bzw. das in der betreffenden Währung/Transaktion festgelegte Datum. In der Stammdaten- Transaktion “Verwalten von Währungen” (DBICUR) kann festgelegt werden, wie viele Valutatage Soll- und Habenseitig dem Tagesdatum hinzuaddiert werden sollen. |
8 | D = Belastung (Debit), C = Gutschrift (Credit) |
9 | Währung - hier wird die ursprüngliche Währung angezeigt |
10 | Originalbetrag - hier wird der ursprüngliche Betrag angezeigt, bevor eine Umrechnung gemacht wurde. |
11 | Icon ![]() |
Für verschiedene Zahlungsarten können zusätzliche Panele aktiv werden, in welche die erforderlichen Informationen für Zahlungsnachrichten eingegeben werden können (z.B. Beteiligte der Zahlung).
Bei einem Splitting wird der Abrechnungsbetrag auf unterschiedliche Konten, ggf. auch in unterschiedliche Währungen aufgeteilt.
In der Praxis kommt es häufig vor, dass der Kunde die Abrechnung des Dokumentenbetrages zu Lasten seines Währungskontos wünscht und die Abrechnung der Gebühren zu Lasten seines Kontos in Systemwährung.
Erfasst werden kann ein Splitting, indem der Benutzer in das Betragsfeld den Betrag einträgt, der dem dort eingetragenen Konto belastet/ gutgeschrieben werden soll.
Wenn das Betragsfeld mit <Tab> verlassen wird, erstellt die Applikation einen weitere Abrechnungszeile und trägt in diese den Differenzbetrag ein.
Der Benutzer kann dann eine Umrechnung oder auch die Buchung auf ein anderes Konto manuell vornehmen.
Dass es sich um einen gesplitteten Betrag handelt, zeigt die Applikation, in dem die Beträge blau und grün angezeigt werden.
Soll ein Splitting gelöscht werden, kann der Benutzer den farbig markierten Betrag löschen und es wird wieder nur eine Abrechnungsbuchung erzeugt.
Über den Eintrag “Geb. separat” kann automatisch ein Splitting vorgenommen werden.
Weitere Informationen dazu finden Sie im Abschnitt Abrechnungs-Details-Panel.
Es gibt Situationen, in denen es zu der Meldung “inkonsistentes Settlement” kommen kann.
Beispiel:
Unter einem Kontrakt sollen demjenigen, der lt.
Kontrakt die Gebühren aus dem Geschäft trägt, Gebühren erstattet werden.
Im 1. Grid wird Zahler “OWN”, als Empfänger die entsprechende Rolle, Dispokennzeichen “X” und Betrag z.B. “EUR 3,00” erfasst.
Daraufhin erscheinen im 2. Grid SWIFT-Gebühren sowie das Panel “Zahlung 202” und verschwinden wieder.
Dies geschieht einige Male bis der Hinweis: “Gebühren- und Abrechnungs-Defaulting ist inkonsistent und daher ausgeschaltet.” erscheint.
Über und
kann diese Aktion immer wieder neu gestartet werden.
Was intern passiert ist folgendes: Die 3 EUR werden dem Beteiligten gutgeschrieben; zur Zahlung wird eine SWIFT-Nachricht erstellt, die den Default einer SWIFT Gebühr nach sich zieht , die den Betrag der Gutschrift übersteigt. Dadurch wird aus der Gutschrift eine Zahlungsverpflichtung, die per Brief abgewickelt wird. Somit entfällt die SWIFT-Nachricht und damit auch die SWIFT Gebühr und das Spiel beginnt erneut.
Die Korrektur kann nur durch manuelle Korrektur der Grunddaten erfolgen.
Variante a.) Die Gebühr selber vereinnahmen und den Beteiligten informieren, dass diese nicht (oder später) weitergegeben wird, da die SWIFT-Kosten den Ertrag übersteigen.
Variante b.) Die SWIFT-Gebühr in den Pool stellen (dazu z.B. den Gebührenbetrag zunächst auf einen die SWIFT-Gebühr übersteigenden Betrag setzen.
Mit [Prüfen] das Settlement alle anderen Daten ausrechnen lassen, die SWIFT-Gebühr auf “Pool” stellen und den Betrag wieder zurücksetzen.
Variante c.) Auf die SWIFT-Gebühr in solchen Fällen verzichten oder diese reduzieren.
Dazu wie bei b.) vorgehen und anschließend den Betrag löschen oder anpassen.
Im Import Akkreditiv Bereich oder bei den Übertragungen kommt es vor, dass Gebühren in der Abrechnungstransaktion gegenüber einer anderen Rolle abgerechnet werden als ursprünglich avisiert. Dies ist ein durchaus gewolltes Verhalten, wie folgendes Beispiel zeigt:
Ein Import Akkreditiv wird avisiert, die Gebührenregelung sieht vor, dass die Gebühren von der Auslandsseite getragen werden und bei Abrechnung des Dokumentensatzes vom Dokumentengegenwert abgezogen werden. Bei Eröffnung des Kontrakts (LITOPN) werden deshalb Gebühren gegenüber der avisierenden Bank (“ADV”) in den Pool gestellt oder avisiert (Disposition “P” oder “V”).
Ist der Einreicher der Dokumente ebenfalls die avisierende Bank, werden die avisierten/ in Pool gestellten Gebühren bei Abrechnung der Dokumente vom Gutschriftsbetrag abgezogen.
In vielen Fällen ist es jedoch so, dass der Dokumentensatz der eröffnenden Bank nicht von der avisierenden Bank präsentiert wird, sondern von einem anderen Einreicher (“PRB”).
Auch in diesem Fall will der Benutzer, dass bei “Dokumente senden, akzeptieren und abrechnen” (BRTPAY) der Einreicher den Dokumentenwert abzüglich der Gebühren für die Auslandsseite gutgeschrieben bekommt.
Der avisierenden Bank werden in der Regel keine Gebühren belastetet, da diese nach Avisierung mit dem Akkreditiv nichts mehr zu tun hat.
D.h. die ursprünglich der avisierenden Bank zugeordneten Gebühren sollen jetzt dem Einreicher in Rechnung gestellt werden.
Zu diesem Zweck wird im Abrechnungsmodul für den Geschäftsbereich festgelegt, dass die “ADV” Gebühren der “PRB” zugerechnet werden.
Da die avisierende Bank und der Einreicher aber unterschiedliche Beteiligte sind, kommt eine Warnung als Erläuterung für den Benutzer.
Für den Fall, dass der Benutzer tatsächlich Gebühren gegenüber der avisierenden Bank abrechnen möchte, sollte dies im Hauptkontrakt, also in diesem Fall im Bereich Import Akkreditiv erfolgen.
Das Panel zeigt die Details der Gebührenberechnung. Diese können abhängig von der Definition der Gebühr manuell verändert werden.
Die Combobox rechts oben zeigt an, welche Details der Gebühr manuell verändert wurden. Durch Auswahl des Eintrags “unverändert/redefault” kann der ursprünglich defaultete Zustand wieder hergestellt werden.
Dieses Panel zeigt Details der Abrechnung an, die entsprechend den Anforderungen verändert werden können.
Die Kurse werden in 3 Zeilen dargestellt, die beteiligten Währungen stehen jeweils vor dem Feld:
Durch Änderung des Kurstyps lassen sich die Kurse zwischen den beteiligten Währungen jeweils auswählen bzw. eingeben. Wurden im Abrechnungs-Details-Panel Kurse voreingestellt, kann hier durch markieren der Checkbox “eigene Kurse definieren” manuell ein davon abweichender Kurs erfasst werden.
Bei Umrechnungen ist zudem ersichtlich, welcher Umrechnungskurs verwendet wurde und von wann dieser ist.
Der von der Applikation vorgeschlagene Umrechnungskurs wird jeweils aus dem Kurs per Valutadatum bzw. bei Valuten größer-gleich Tagesdatum aus dem zuletzt gespeicherten Kurs ermittelt.
Anstatt des automatisch vom System vorgeschlagenen Umrechnungskurs kann auch ein freier Kurs erfasst werden, der dann als Berechnungsgrundlage für die Umrechnung dient.