Erweiterungen
Die Bankcodes wurden überarbeitet. Bei der Eingabe eines SWIFT-Codes wird der Code nun geprüft. Es sind nur SWIFT-Codes mit Länge 8 und 11 möglich. Weiters dürfen die ersten 6 Stellen nur Buchstaben, die restlichen Stellen nur Buchstaben und Zahlen enthalten.
Die Bankcode-Tabelle wurde erweitert. Es wird in der Übersicht jetzt auch der ISO Ländercode der Bank angezeigt. Bei der Eingabe eines neuen SWIFT-Codes wird der ISO Ländercode aus dem SWIFT-Code ermittelt. Zusätzlich werden in der Einrichtung der Codes die Anzahl der zugeordneten Bankkonten und Debitor/Kreditor Bankkonten getrennt nach SWIFT-Code und BLZ angezeigt.
Beim Import/Export und Download der Bankcodes gibt es (falls bereits Daten in der Tabelle vorhanden sind) jetzt folgende Optionen:
- Datensätze anlegen wenn nicht vorhanden
legt nur neue Bankcodes an.
- Datensätze anlegen & vorhandene Datensätze überschreiben
überschreibt bzw. aktualisiert die vorhandenen Codes (z.B. Feld Name).
Werden die Bankcodes über die Funktion Download abgerufen (bzw. Import mit aktuellem Bankcode-File) werden Bankcodes welche nicht mehr im aktuellen Verzeichnis der Österreichischen bzw. Deutschen Nationalbanken enthalten sind als Veraltet gekennzeichnet. Das Feld Veraltet kann auch manuell gesetzt werden. |
| In der Zahlungsverkehr Einrichtung wurden im Register Version die Felder Datum der Bank Codes, Datum der Zahlungsverkehr Codes und Datum der XML Schemata hinzugefügt.
Diese Felder zeigen das Datum des jeweiligen Datenbestandes an, welcher über Import/Download importiert wurde. Mit AssistEdit im Feld kann die Einrichtung der jeweiligen Daten geöffnet werden.
Über What's New? hat man die Möglichkeit das jeweilige Datum mit den bereitgestellten Download-Daten zu vergleichen. |
| Die Zahlungsposten können jetzt auch direkt vom Debitor/Kreditor aus aufgerufen werden. |
| Über AssistEdit im MT940 Import, Feld Importierte Datei ist es nun möglich den Ordner von welchem die MT940 Datei importiert wurde zu öffnen. |
| Im Zahlungsvorschlag wurde in den Optionen ein neues Feld Letztes Skontodatum hinzugefügt.
Ist das Feld Skonto finden im Zahlungsvorschlag gesetzt wird auf das Skontodatum der Posten jetzt mit diesem Feld gefiltert und nicht mehr mit dem Feld Letztes Fälligkeitsdatum. Ist das Feld leer wird wie bisher das Feld Letztes Fälligkeitsdatum für den Filter verwendet.
In der Zahlungsverkehr Einrichtung wurde ein neues Feld Skontodatumsformel hinzugefügt.
Ist das Feld gefüllt wird damit beim Aufruf des Zahlungsvorschlags das Feld Letztes Skontodatum auf Basis des Arbeitsdatums vorbelegt. |
| In der Zahlungsverkehr Einrichtung wurde ein neues Feld Fälligkeitsdatumsformel hinzugefügt.
Ist das Feld gefüllt wird damit beim Aufruf des Zahlungsvorschlags das Feld Letztes Fälligkeitsdatum auf Basis des Arbeitsdatums vorbelegt. |
| In der Zahlungsverkehr Einrichtung wurde ein neues Feld Buchungsdatumsformel hinzugefügt.
Ist das Feld gefüllt wird damit beim Aufruf des Zahlungsvorschlags das Feld Buchungsdatum auf Basis des Arbeitsdatums vorbelegt. |
| Im Zahlungsvorschlag wurde in den Optionen ein neues Feld Ohne Minderungen hinzugefügt. Ist dieses Feld gesetzt werden Posten welche den Betrag mindern würden, also z.B. Gutschriften nicht abgerufen. |
| Die Zahlungsvorschlagsliste wurde erweitert. Es wird jetzt auch die Belegnr. des Debitoren/Kreditorenpostens angedruckt. |
| In den Tabellen 21 Debitorenposten und 25 Kreditorenposten wurde ein neues Feld Zahlungsreferenz hinzugefügt.
Dieses Feld wird im Zahlungsvorschlag berücksichtigt.
Funktionsweise:
Ist das Feld Zahlungsreferenz in den Kreditoren/Debitorenposten gefüllt wird beim Zahlungsvorschlag das Feld Zahlungsreferenz im Buchblatt mit diesem Wert vorbelegt.
Das Feld Zahlungsreferenz in den Kreditoren/Debitorenposten kann in der Form Kreditorenposten bzw. Debitorenposten vom Benutzer mit F2 geändert werden.
Das Feld ist standardmäßig in den Kreditoren/Debitorenposten leer, es wird also nicht vom Zahlungsverkehr vorbelegt. Über eine Individualprogrammierung ist es möglich eine spezielle Logik aufzubauen damit dieses Feld beim Buchen eines Belegs oder an anderen Stellen gefüllt wird. Der Zahlungsverkehr würde das Feld beim Abruf des Zahlungsvorschlags im Buchblatt berücksichtigen. |
| Die XML Schemata wurden überarbeitet.
Folgende Änderungen wurden durchgeführt:
Der ISO Ländercode kann jetzt geändert werden bzw. muss jetzt nicht mehr angegeben sein.
Wenn ein ISO Ländercode bei einem XML Schema hinterlegt ist muss der ISO Ländercode des Bankkontos mit dem ISO Ländercode des Schemas bei der Erstellung der Zahlungsdatei übereinstimmen.
Das Feld IBAN Only möglich zeigt an ob das Schema auch Transaktionen ohne die Angabe von SWIFT-Code unterstützt. (Anmerkung: der SWIFT-Code im eigenen Bankkonto muss immer angegeben werden) Ist IBAN Only möglich können die Felder IBAN Only Inland und IBAN Only Ausland gesetzt werden.
Ist IBAN Only Inland gesetzt sind Inlandstransaktionen auch ohne SWIFT-Code erlaubt.
Ist IBAN Only Ausland gesetzt sind Auslandstransaktionen auch ohne SWIFT-Code erlaubt. Wird voraussichtlich erst ab 2016 benötigt.
Das Feld Sammelbuchung bestimmt wie die Transaktion Bankseitig gebucht wird. Standardmäßig ist dieses Feld leer und wird auch nicht in die Zahlungsdatei geschrieben.
Bei der Angabe von Ja oder Nein wird der Indikator ob es sich um eine Sammelbuchung (Ja) oder eine Einzelbuchung handelt (Nein)in der Zahlungsdatei gesetzt.
Nur wenn eine entsprechende Vereinbarung für Einzelbuchungen mit dem Kunden vorliegt, wird im Falle von Belegung mit Nein jede Transaktion einzeln auf dem Kontoauszug des Auftraggebers dargestellt. Andernfalls bzw. standardmäßig handelt es sich immer um eine Sammelbuchung (default/pre-agreed: Ja).
Das Feld Spesenangabe möglich zeigt an ob das Schema die Angabe von Spesen erlaubt.
Das Feld Eilzahlung möglich zeigt an ob das Schema Eilzahlung unterstützt.
Datum der Spezifikation und Korrigiert am zeigen interne Informationen zum Schema.
In Verwendung zeigt an ob das Schema Bankkonten zugeordnet ist.
Nach einem Update von einer früheren Zahlungsverkehr Version müssen die Schemata über Download oder Import aktualisiert bzw. neu angelegt werden.
Die Zuordnung der Bankkonten sollte danach ebenfalls überprüft werden da sich teilweise die Schema-Codes geändert haben. |
| Der Zahlungsverkehr wurde um die Möglichkeit erweitert Non-SEPA Überweisung zu erstellen.
Um für ein Bankkonto eine Non-SEPA Überweisung zu erstellen muss dem Bankkonto das entsprechende Schema zugeordnet werden. |
| Neben Lastschriftart CORE und B2B wurde eine neue Lastschriftart COR1 hinzugefügt. |
| Die Sprachcode Tabelle wurde um das Feld Alternativer Sprachcode Zahlungsverkehr erweitert. Funktionsweise: Siehe nachfolgende Punkte. |
| Im Bericht Debitor SEPA Mandat Formular kann man nun über die Optionen im Bericht jetzt einstellen ob Name und Adresse des Debitors bzw. IBAN und SWIFT-Code des Debitor Bankkontos angedruckt werden soll. Zusätzlich wird jetzt neben der Mandat ID auch die Lastschriftart und Lastschriftsequenz angedruckt. |
Die SEPA Mandatstexte wurden erweitert. Es können nun unterschiedliche Textbausteine je nach Lastschriftart und Lastschriftsequenz angelegt werden.
Im Bericht Debitor SEPA Mandat Formular wird nach folgender Logik der Textbaustein ermittelt:
| Lastschriftart | Lastschriftsequenz | Sprachcode |
|---|
| Des Mandats | Des Mandats | Des Debitors |
| Des Mandats | Alle | Des Debitors |
| Alle | Des Mandats | Des Debitors |
| Alle | Alle | Des Debitors |
| Des Mandats | Des Mandats | Alternativer Sprachcode |
| Des Mandats | Alle | Alternativer Sprachcode |
| Alle | Des Mandats | Alternativer Sprachcode |
| Alle | Alle | Alternativer Sprachcode |
Es wird also zuerst versucht einen Textbaustein mit dem Sprachcode des Debitors zu finden.
Dabei wird zuerst nach einem Textbaustein für genau die Lastschriftart und Lastschriftsequenz des Mandats gesucht, falls kein Textbaustein vorhanden ist, wird nach der Lastschriftart des Mandats und der Lastschriftsequenz Alle gesucht usw.
Wurde für den Sprachcode des Debitors kein Textbaustein gefunden wird mit dem Alternativer Sprachcode Zahlungsverkehr, welcher jedem Sprachcode zugeordnet werden kann, gesucht.
Das wird nur dann gemacht wenn der Debitor einen Sprachcode angegeben hat.
Hat der Debitor keinen Sprachcode hinterlegt, wird nach Textbausteinen ohne Sprachcode gesucht.
Hat der Debitor einen Sprachcode hinterlegt, für diesen wurde aber kein Textbaustein gefunden und der Alternativer Sprachcode Zahlungsverkehr ist leer wird ebenfalls nach Textbausteinen ohne Sprachcode gesucht.
Wird kein Textbaustein gefunden wird das Debitor SEPA Mandat Formular ohne einen Textbaustein gedruckt. |
Die Externe Bankkontosuche in der Zahlungsverkehr Einrichtung wurde um die Option Letzte Transaktion/Hauptbankverbindung erweitert.
Diese Option vereint die beiden bisherigen Optionen.
Es wird also beim Zahlungsvorschlag, falls keine entsprechende Transaktion gefunden wird, danach weiter nach der Hauptbankverbindung gesucht.
Falls nur ein Bankkonto existiert wird dieses verwendet.
Je nachdem wie das eigene Bankkonto eingestellt ist und welche Zahlungsart gewählt wurde wird das gefundene externe Bankkonto vorgeschlagen oder nicht.
Bedingungen für das Vorschlagen des externen Bankkontos:
Bei Zahlungsart SEPA:
- Wenn der Ländercode des eigenen und des externen Bankkontos SEPA gesetzt haben.
- Der ISO Währungscode der Transaktion EUR ist.
Bei Zahlungsart Non-SEPA:
- wenn Zahlungsart SEPA nicht möglich ist.
Bei EDIFACT Inland (PAYMUL/DIRDEB):
- Wenn das eigene und das externe Bankkonto im ISO Ländercode als 'AT' definiert sind.
- Der ISO Währungscode der Transaktion EUR ist.
Bei EDIFACT Ausland (PAYMUL):
- wenn Zahlungsart EDIFACT Inland nicht möglich ist.
- Das eigene Bankkonto im ISO Ländercode als 'AT' definiert ist.
- Das externe Bankkonto im ISO Ländercode einen Wert hat (kann auch 'AT' sein z.B. wenn ISO Währungscode der Transaktion nicht EUR ist bzw. Inland nicht möglich ist).
Bei MT101 Inland:
- Wenn der ISO Ländercode des eigenen Bankkontos ident mit dem ISO Ländercode des externen Bankkontos ist.
Bei MT101 Ausland:
- wenn Zahlungsart MT101 Inland nicht möglich ist.
|
| Im Zahlungsvorschlag wird wie bisher bei SEPA Überweisung, SEPA Lastschrift, Inlandsüberweisung (PAYMUL) und Lastschrift (DIRDEB) nach Währungen mit ISO Währungscode 'EUR' gefiltert. Ist die Mandantenwährung in 'EUR' definiert werden auch Posten ohne Währungscode berücksichtigt.
Bei Zahlungsart Überweisungsvorschlag, Auslandsüberweisung (PAYMUL), Non-SEPA Überweisung und MT101 Auslandsüberweisung gibt es im Zahlungsvorschlag nun die Möglichkeit das neuen Feld Fremdwährungsfilter zu setzen.
Ist das Feld gesetzt wird nach Währungen mit ISO Währungscode ungleich 'EUR' gefiltert. Ist die Mandantenwährung nicht in 'EUR' definiert werden auch Posten ohne Währungscode berücksichtigt.
Bei MT101 Inlandsüberweisung wird nicht nach Währungen gefiltert.
Wenn nach einer Währung gefiltert wurde erscheint nach dem Abruf ein Hinweis, dass unter Umständen auch noch offene Posten in anderen Währungen vorhanden sind. |
Im Zahlungsvorschlag wurde die Option Zahlungsart für Kreditoren um die Option Überweisungsvorschlag, für Debitoren um die Optionen Lastschriftvorschlag und Überweisungsvorschlag erweitert.
Wird eine der beiden Optionen gewählt wird folgendes gemacht:
- Es wird nicht nach Währungscode gefiltert.
- Es wird versucht in Verbindung mit der Einstellung der Externen Bankkontosuche und dem eigenen Bankkonto das externe Bankkonto und die Zahlungsart zu ermitteln.
Hier gilt folgendes:
Bei Lastschriftvorschlag werden wie bisher Transaktionen des Debitors innerhalb des Währungscodes gesucht. Da die Zahlungsart aber zu diesem Zeitpunkt nicht feststeht wird nach SEPA Lastschrift und Lastschrift (DIRDEB) gesucht.
Bei Überweisungsvorschlag werden wie bisher Transaktionen des Kreditors/Debitors innerhalb des Währungscodes gesucht. Da die Zahlungsart aber zu diesem Zeitpunkt nicht feststeht wird nach SEPA Überweisung, Inlandsüberweisung (PAYMUL), Auslandsüberweisung (PAYMUL), Non-SEPA Überweisung, MT101 Inlandsüberweisung und MT101 Auslandsüberweisung gesucht.
Wird eine Transaktion gefunden wird die Zahlungsart und der externe Bankkontocode der Transaktion vorgeschlagen.
Wurde keine Transaktion gefunden wird nach den Regeln der externen Bankkontosuche versucht das externe Bankkonto und die Zahlungsart zu ermitteln:
Dabei wird bei Lastschriftvorschlag zuerst versucht eine SEPA Lastschrift zu erstellen sofern die Regeln der externen Bankkontosuche zutreffen und das eigene Bankkonto ein SEPA Lastschrift Schema hinterlegt hat. Erst danach wird versucht eine Lastschrift (DIRDEB) zu erstellen.
Bei Überweisungsvorschlag wird zuerst versucht eine SEPA Überweisung zu erstellen sofern die Regeln der externen Bankkontosuche zutreffen und das eigene Bankkonto ein SEPA Überweisung Schema hinterlegt hat. Danach wird versucht eine Non-SEPA Überweisung zu erstellen wenn das eigene Bankkonto ein Non-SEPA Überweisung Schema hinterlegt hat. Erst danach wird versucht eine Inlandsüberweisung (PAYMUL) zu erstellen, gefolgt von der Auslandsüberweisung (PAYMUL).
Bei MT101 Inlandsüberweisung und MT101 Auslandsüberweisung wird nicht versucht zu erstellen.
Trotzdem können auch diese Zahlungsarten vorgeschlagen werden und zwar wenn schon eine Transaktion gefunden wurde.
Ist also die Externe Bankkontosuche so eingestellt das letzte Transaktionen berücksichtigt werden und z.B. die letzte USD – Transaktion des Kreditors/Debitors mit MT101 Auslandsüberweisung durchgeführt wurde wird bei weiteren USD – Transaktionen so lange MT101 Auslandsüberweisung vorgeschlagen bis eine Transaktion in USD mit einer anderen Zahlungsart durchgeführt wurde.
Die Externe Bankkontosuche, vor allem mit der Option Letzte Transaktion/Hauptbankverbindung in Verbindung mit Lastschrift/Überweisungsvorschlag sollte in den meisten Fällen die optimalen Ergebnisse liefern. |
| Im Zahlungsausgangs Buch.-Blatt und Zahlungseingangs Buch.-Blatt wurde ein neuer Menüpunkt Zahlungsstatistik hinzugefügt.
Die Zahlungsstatistik zeigt alle Beträge des Buch.-Blatts summiert nach Zahlungsart an. |
| Im Zahlungsausgangs Buch.-Blatt und Zahlungseingangs Buch.-Blatt wurde ein neuer Menüpunkt Belegnummern neu nummerieren im Button Funktion hinzugefügt.
Die Funktion erstellt dabei für alle im Buch.-Blatt vorhandenen Zeilen, bei denen weder Scheck gedruckt noch Zahlungsdatei erstellt gesetzt ist, die Belegnr. neu.
Anmerkung NAV2013 R2:
Ab NAV 2013 R2 ist die Funktion Belegnummern neu nummerieren standardmäßig in den Buch.-Blättern vorhanden. Diese Funktion wurde im Zahlungsausgangs Buch.-Blatt und Zahlungseingangs Buch.-Blatt durch die Funktion aus dem Zahlungsverkehr ersetzt. Die Funktion aus dem Zahlungsverkehr verwendet eine andere Logik für die Neuvergabe der Belegnummern und berücksichtigt dabei auch Buch.-Blattzeilen für welche bereits eine Zahlungsdatei erstellt wurde. |
| Im Zahlungsvorschlag wurde die Belegnummernvergabe geändert. Es werden jetzt bereits vorhandene Belegnummern in den Buch.-Blattzeilen berücksichtigt und nicht noch einmal vergeben.
Weiters wird das Feld Start von Belegnr. auf die nächste freie Nummer der Nummernserie gesetzt.
Der Abruf überspringt Belegnummern die bereits im Buch.-Blatt verwendet werden. |
| Bei Zahlungsdatei erstellen wurden die Optionen und die Dateierstellung selbst geändert.
Die Optionen bzw. deren Verfügbarkeit bei Zahlungsdatei erstellen sind abhängig von der der gewählten Bankkontonr. und den dahinter zugeordneten Schemata, der Zahlungsart und der Lastschriftart.
Es wurde ein neues Feld Durchführungsdatum Einmalige/Erste Lastschrift hinzugefügt.
Es wurde ein neues Feld Spesen hinzugefügt.
Es wurde ein neues Feld Eilzahlung hinzugefügt.
Die Vorbelegung/Berechnung des Durchführungsdatums hat sich geändert.
Das Durchführungsdatum wird jetzt folgendermaßen berechnet:
Wird Eilzahlung aktiviert ist wird das Durchführungsdatum auf den heutigen Tag gesetzt.
Ansonsten wird das Durchführungsdatum auf den nächsten Tag gesetzt, außer es handelt sich um eine SEPA Lastschrift in Verbindung mit Lastschriftart CORE - Basislastschrift, in diesem Fall wird das Durchführungsdatum auf Heute + 2 Tage gesetzt.
Das Durchführungsdatum Einmalige/Erste Lastschrift ist nur bei SEPA Lastschrift in Verbindung mit Lastschriftart CORE - Basislastschrift verfügbar und wird folgendermaßen berechnet:
Heute + 5 Tage.
Die Option Spesen ist verfügbar unter folgenden Bedingungen:
Bei Zahlungsart Auslandsüberweisung (PAYMUL) oder wenn das XML Schema des Bankkontos für die gewählte Zahlungsart Spesen unterstützt.
Das Feld wird im Zahlungsposten gespeichert.
Diese Option Eilzahlung ist verfügbar wenn das XML Schema des Bankkontos für die gewählte Zahlungsart Eilzahlungen unterstützt.
Das Feld wird im Zahlungsposten gespeichert.
Durch einige grundsätzliche strukturelle Änderungen bzw. Funktionserweiterungen werden jetzt bei der Dateierstellung folgende Transaktionen in einem Auftragsbestand (B-Level) zusammengefasst:
Transaktionen mit selben Währungscode (bisher nur bei EDIFACT Dateien), selber Lastschriftart, Lastschriftsequenz und selben Durchführungsdatum.
Die Lastschriftsequenz (früher Bankeinzugsart) wurde entfernt.
Es werden jetzt alle Lastschriftsequenzen in eine Zahlungsdatei geschrieben.
Pro Lastschriftsequenz wird ein Auftragsbestand geschrieben.
Es wird automatisch von Lastschriftsequenz Erster auf Wiederkehrend gewechselt sobald eine weitere Transaktion in der Datei vorkommt. In diesem Fall wird auch das Durchführungsdatum der wiederkehrenden Transaktionen und falls vorhanden letzten Transaktion auf das Durchführungsdatum der ersten Transaktion gesetzt. Das neue Feld Urspr. Lastschriftsequenz in der Buch.-Blattzeile wird befüllt, wenn sich die Sequenz durch die Dateierstellung automatisch ändert. Wird die Transaktion annulliert wird die Lastschriftsequenz wieder zurückgesetzt. |
| Die Vorgaben in neueren Rulebooks für XML SEPA/Non-SEPA Dateien wurden geändert.
Bei Verwendung eines solchen Schemas wird die Transaktionsreferenz in die EndToEndId geschrieben. Damit ist eine Eindeutige ID für eine spätere Zuordnung vorhanden.
Das bedeutet aber auch, dass, falls eine Zahlungsreferenz angegeben wurde, diese nicht mehr in die EndToEndId geschrieben werden kann. In dem Fall wird die Zahlungsreferenz als strukturierter Verwendungszweck in die Datei geschrieben. Ein unstrukturierter Verwendungszweck ist in diesem Fall nicht mehr vorhanden bzw. nicht erlaubt.
Bei älteren Schemen verändert sich nichts bzw. gibt es folgende Vorgaben:
Es wird weiterhin die Zahlungsreferenz (bzw. NOTPROVIDED falls keine Zahlungsreferenz angegeben ist) in die EndToEndId geschrieben. Eine Angabe einer Transaktionsreferenz ist hier nicht möglich. Auch ist bei Angabe einer Zahlungsreferenz kein Verwendungszweck erlaubt bzw wird kein Verwendungszweck in die Datei geschrieben. |
| Über AssistEdit im Clearingposten, Feld Erstellte Datei ist es nun möglich den Ordner in welchem die Zahlungsdatei erstellt wurde zu öffnen. |
| Es gibt jetzt eine neue Auswertung Clearingliste. Diese Liste Zeigt Informationen zur erstellten Zahlungsdatei an. Die Liste kann vom Buch.-Blatt, vom Clearingposten oder vom Zahlungsverkehr Menü aufgerufen werden. |
| Das Feld Status im Clearingposten wurde um die Option Gebucht erweitert. Der Status wird auf Gebucht gesetzt sobald das Buch.-Blatt gebucht wird. |
| Beim Annullieren eines bereits gebuchten Clearingpostens kommt nun eine weitere Rückfrage. |
Der Avis kann jetzt auch per E-Mail verschickt werden.
Der Avis E-Mail Vorschlag kann überall aufgerufen werden wo auch Avis drucken aufgerufen werden kann.
Funktionsweise:
Nachdem die Zahlungsdatei erstellt wurde kann man wie bisher den Avis drucken oder jetzt auch per E-Mail verschicken. Über den Menüpunkt Avis E-Mail Vorschlag wird zuerst ein Vorschlag erstellt. Dieser Vorschlag wird nicht gespeichert sondern bei jedem Aufruf von Avis E-Mail Vorschlag neu generiert.
Die E-Mail Adresse an den der Avis geschickt werden soll, wird über das neue Feld Avis E-Mail (Register Kommunikation) beim Debitor bzw. Kreditor hinterlegt. Standardmäßig wird nur für diejenigen Debitoren/Kreditoren ein Vorschlag erstellt, die in diesem Feld eine E-Mail Adresse hinterlegt haben.
Ist die Option Inklusive Konten ohne Avis E-Mail beim Vorschlag gesetzt werden auch Debitoren/Kreditoren ohne Avis E-Mail vorgeschlagen.
Als Ergebnis des Vorschlags erhält man eine Übersicht mit allen Daten welche man anschließend kontrollieren, überarbeiten und abschließend senden kann.
Der Betreff und der Textbaustein für die E-Mails wird in der Zahlungsverkehr Einrichtung unter dem Menüpunkt Avis Text hinterlegt.
Der Text kann je nach Sprachcode hinterlegt werden.
Der Vorschlag versucht den Sprachcode für den Avis Text folgendermaßen zu ermitteln:
- Über den Sprachcode des Debitors
- Alternativer Sprachcode
Es wird also zuerst versucht einen Textbaustein mit dem Sprachcode des Debitors zu finden.
Wurde für den Sprachcode des Debitors kein Textbaustein gefunden wird mit dem Alternativer Sprachcode Zahlungsverkehr, welcher jedem Sprachcode zugeordnet werden kann, gesucht.
Das wird nur dann gemacht wenn der Debitor einen Sprachcode angegeben hat.
Hat der Debitor keinen Sprachcode hinterlegt, wird nach Textbausteinen ohne Sprachcode gesucht.
Hat der Debitor einen Sprachcode hinterlegt, für diesen wurde aber kein Textbaustein gefunden und der Alternativer Sprachcode Zahlungsverkehr ist leer wird ebenfalls nach Textbausteinen ohne Sprachcode gesucht.
Wird kein Textbaustein gefunden wird der Sprachcode des Debitors im Feld Sprachcode Avis Text im Vorschlag angezeigt.
Wird ein Textbaustein gefunden wird in das Feld Sprachcode Avis Text der Sprachcode des Textbausteins geschrieben.
Der Sprachcode kann vor dem Senden noch verändert werden.
Ein E-Mail kann nur dann gesendet werden, wenn ein Avis Text mit einem E-Mail Betreff existiert.
Hat der Avis Text zusätzlich einen E-Mail Text hinterlegt wird dieser als Text in das Mail geschrieben.
Nachdem alle Daten kontrolliert wurden kann man jedes einzelne Mail oder Alle senden.
Avis Mails werden über SMTP gesendet. Dafür wurde die Zahlungsverkehr Einrichtung erweitert.
Im Register Avis findet man alle notwendigen Einstellungen für den SMTP-Server. Hier kann man auch hinterlegen ob alle gesendeten Avis Mails als Kopie oder Blind-Kopie an eine weitere Adresse gesendet werden sollen (z.B. für interne Archivierungen, Benachrichtigungen usw.).
Beim Senden der E-Mail wird der Avis Report als HTML Datei bzw. in neueren NAV Releases als PDF Datei im Anhang des E-Mails mitgeschickt.
Im Zahlungsposten wird dabei das Feld Avis E-Mail gesendet auf Ja gesetzt und die Adresse, Zeit und Datum des E-Mails werden gespeichert. Wird ein Avis erneut gesendet werden diese Daten aktualisiert bzw. überschrieben. |
| Im Clearingposten wurden die Felder Anzahl Avis und Avis nicht gedruckt/gesendet hinzugefügt.
Das Feld Anzahl Avis zeigt die Anzahl der Avis an, welche zu diesem Clearingposten existieren.
Das Feld Avis nicht gedruckt/gesendet zeigt an, wie viele Avis noch gedruckt oder per E-Mail gesendet werden müssen. |
| Im Zahlungsausgangs Buch.-Blatt und Zahlungseingangs Buch.-Blatt wurden die Felder Durchführungsdatum, Avis gedruckt und Avis E-Mail gesendet hinzugefügt. Diese 3 Felder zeigen die jeweiligen Daten aus dem Zahlungsposten an. |
| In den Zahlungsposten wurde das Feld Anzahl Bankposten hinzugefügt. Dieses Feld entspricht dem Feld Anzahl Bankposten aus den Clearingposten, zeigt allerdings nur Bankposten zu einem Zahlungsposten an. |
| In der Zahlungsvorschlagsliste wird jetzt nach jeder Buch.-Blattzeile eine Linie angedruckt. Die Aufteilung des Zeilenbetrags bzw. der Ausgleich ist dadurch auch am Bericht ersichtlich. |
Änderungen
Die MT940 Buchungscodes und MT940 Geschäftsvorfallcodes wurden in eine gemeinsame neue Tabelle Zahlungsverkehr Codes zusammengelegt.
Diese Tabelle wird ab jetzt für alle Codes verwendet.
Für Zahlungsverkehr Codes stehen Import/Export und Downloadfunktionen zur Verfügung.
Beim Import/Export und Download der Zahlungsverkehr Codes gibt es (falls bereits Daten in der Tabelle vorhanden sind) jetzt folgende Optionen:
- Datensätze anlegen wenn nicht vorhanden
legt nur neue Zahlungsverkehr Codes an.
- Datensätze anlegen & vorhandene Datensätze überschreiben
überschreibt bzw. aktualisiert die vorhandenen Codes (z.B. Feld Beschreibung).
|
| Der Aufruf der Clearingposten über ein Bankkonto zeigt keine annullierten Posten mehr. Der Filter kann durch den Benutzer aufgehoben werden. |
| Der Aufruf der Zahlungsposten über ein Bankkonto bzw. Debitor/Kreditor Bankkonto zeigt keine annullierten Posten mehr. Der Filter kann durch den Benutzer aufgehoben werden. |
| Das Feld Buchungscode im MT940 Import wurde in SWIFT Transaktionscode umbenannt. |
| Das Feld Gegenkontoart im Zahlungsposten wurde in Kontoart umbenannt.
Das Feld Gegenkontonr. im Zahlungsposten wurde in Kontonr. umbenannt. |
| Bankeinzugsmethode wurde in Lastschriftart umbenannt.
Bankeinzugsart wurde in Lastschriftsequenz umbenannt. |
| Die Darstellung der Zahlungsdatei-Einstellungen in der Zahlungsverkehr Einrichtung wurde geändert.
Die Einstellungen werden nun in einer übersichtlicheren tabellarischen Form angezeigt. |
| Das Feld Gegenkonto Sammelbuchungszeile erstellen in der Zahlungsverkehr Einrichtung wurde in Gegenkontozeile erstellen umbenannt.
Eine Gegenbuchungszeile wird jetzt nur mehr erstellt, wenn mehr als eine Buch.-Blattzeile für eine Gegenbuchungszeile vorhanden ist.
Weiters wurde das Verhalten bei der Zusammenfassung von Buch.-Blattzeilen mit unterschiedlichen Belegarten (Zahlung, Erstattung,…) verändert.
Bisher wurden diese Zeilen zu einer Gegenbuchungszeile zusammengefasst und man konnte das Buch.-Blatt nicht mehr buchen.
Das wurde korrigiert.
Bei unterschiedlichen Belegarten wird die Gegenbuchungszeile jetzt nur mehr dann erstellt, wenn alle beteiligten Buch.-Blattzeilen eine Ausgleich mit Belegnr. gesetzt haben. Ist dies der Fall wird dabei bei allen betroffenen Buch.-Blattzeilen die Belegart auf Zahlung gesetzt. |
| Das Feld Zahlungsreferenz wurde von Numerisch auf Alphanumerisch geändert und auf 35 Stellen erweitert. Bei der Eingabe einer Zahlungsreferenz im Buch.-Blatt wird diese nicht mehr automatisch mit führenden Nullen auf 12 Stellen ergänzt. |
Es können jetzt beliebig viele SEPA Mandate zu einem Debitor Bankkonto zugeordnet werden.
SEPA Mandate werden jetzt nicht mehr direkt am Debitor Bankkonto hinterlegt sondern in einer dahinterliegenden Tabelle.
Über den Menüpunkt SEPA Mandate in der Debitor Bankkontokarte können die Mandate hinterlegt werden.
Funktionsweise:
Eine Mandat ID kann pro Debitor Bankkonto nur einmal vergeben werden. Es ist aber möglich dieselbe Mandat ID auch in anderen Debitor Bankkonten zu verwenden. In diesem Fall erscheint ein Hinweistext das die Mandat ID bei mindestens einem weiteren Debitor Bankkonto verwendet wird.
Die Lastschriftsequenz bestimmt, ob es sich um ein Einmaliges oder ein Wiederkehrendes Mandat handelt.
Das Feld Anzahl Zahlungsposten zeigt die Anzahl der Zahlungsposten (unabhängig von der Lastschriftsequenz) für das Mandat an.
Das Feld Letzte Lastschrift erstellt zeigt an ob ein Zahlungsposten mit Lastschriftsequenz Letzter vorhanden ist.
Das Feld Erste Lastschrift erstellt kann manuell gesetzt werden falls es zwar noch keine Zahlungsposten für das Mandat gibt, das Mandat aber schon in anderen Systemen bzw. vor einer Datenübernahme verwendet wurde.
Der Zahlungsvorschlag versucht Mandate aufgrund folgender Regeln zu ermitteln:
Es werden nur Mandate berücksichtigt:
- Bei denen das Feld Mandat erteilt am ausgefüllt und vor oder gleich dem Tagesdatum ist/liegt.
- Bei denen das Feld Mandat gültig bis leer, nach oder gleich dem Tagesdatum ist/liegt.
Sobald ein Mandat gefunden wurde wird ermittelt ob es dazu schon Zahlungsposten gibt.
Bei einmaligen Mandaten wird geprüft ob das Feld Erste Lastschrift erstellt gesetzt ist oder ob bereits Zahlungsposten vorhanden sind. Ist das der Fall wird nach dem nächsten Mandat gesucht. Ansonsten wird das Mandat vorgeschlagen.
Bei Wiederkehrenden Mandaten wird geprüft ob ein Zahlungsposten mit Lastschriftsequenz Letzter vorhanden ist. Ist das der Fall wird nach dem nächsten Mandat gesucht. Ansonsten wird das Mandat vorgeschlagen. Die Lastschriftsequenz wird dabei auf Erster gesetzt wenn noch kein Zahlungsposten vorhanden ist und das Feld Erste Lastschrift erstellt nicht gesetzt ist. Ansonsten wird die Lastschriftsequenz auf Wiederkehrend gesetzt.
Eine Änderung der Daten im Buch.-Blatt bzw. eine manuelle Vergabe von Mandaten im Buch.-Blatt, welche nicht beim Debitor Bankkonto hinterlegt wurden ist wie bisher weiterhin möglich.
Das Feld Mandat ID kann auch über ein Lookup im Buch.-Blatt ausgewählt werden. |
| Bisher wurde zu jedem Zahlungsposten die Belegnr. und das Buchungsdatum der Buch.-Blattzeile gespeichert.
Je nach Einstellungen im Zahlungsverkehr kann es sein, das für mehrere Buch.-Blattzeilen nur ein Zahlungsposten existiert. Sollte es in diesem Fall unterschiedliche Daten in den beiden Feldern der Buch.-Blattzeilen geben, wurden die Felder im Zahlungsposten nicht befüllt.
Beim Buchen der Buch.-Blattzeilen kann es weiters vorkommen, dass je nach Einstellung der Nummernserie bzw. Buchungsnr.-Serie die Belegnr. bei der Buchung neu vergeben wird.
Ein Navigate war in diesem Fall nicht mehr möglich bzw. brachte falsche Ergebnisse.
Aus diesem Grund wurde eine neue Tabelle Zahlungsbuchungsposten angelegt welche zu jedem Zahlungsposten die während der Buchung entstehenden Belegnummern und Buchungsdatumswerte zu diesem Zahlungsposten speichert.
Das neue Feld Anzahl Zahlungsbuchungsposten im Zahlungsposten zeigt die Anzahl der dahinterliegenden Belegnummern bzw. Buchungsdatumswerte an.
Die neunen Felder Gebucht mit Belegnr. und Gebucht mit Buchungsdatum im Zahlungsposten zeigen jeweils die Werte des ersten Zahlungsbuchungspostens an.
Navigate verwendet nur mehr diese tatsächlich gebuchten Werte.
Wird Navigate direkt im Zahlungsposten aufgerufen und es existieren mehrere Zahlungsbuchungsposten zum Zahlungsposten wird Navigate mit dem ersten gefundenen Datensatz aufgerufen.
Die Felder Belegnr. und Buchungsdatum im Zahlungsposten wurden entfernt. |
| XML bzw. SEPA und Non-SEPA Zahlungsdateien unterstützen jetzt mehrere Auftragsbestände (B-Level) innerhalb einer Datei. |
| Die Generierung der Auftragsreferenz (Bestandskontrollnr.) und Transaktionsreferenz (Auftraggeberreferenz) wird nun bei der Erstellung der Zahlungsverkehrsdatei unabhängig von der Zahlungsart immer nach demselben Schema generiert. Basis für die Referenzfelder ist wie bisher auch die Dateireferenz. |
Die erlaubten Zeichenausnahmen für Österreichische Bankkonten wurden geändert.
Grundsätzlich sind folgende Zeichen erlaubt:
abcdefghijklmnopqrstuvwxyz
ABCDEFGHIJKLMNOPQRSTUVWXYZ
0123456789
/-?:().,'+
Leerzeichen
Bisher war es so, dass bei Österreichischen Bankkonten zusätzlich folgende Zeichen erlaubt waren:
&;
Zusätzlich wurden folgende Zeichen automatisch konvertiert:
< wurde zu '<'
> wurde zu '>'
& wurde zu '&'
" wurde zu '"'
' wurde zu '''
Diese automatische Konvertierung wurde geändert.
Im XML Schema kann nun das Feld Erweiterter Zeichensatz gesetzt werden. Ist das Feld gesetzt wird in diesem Schema die oben genannte Konvertierung durchgeführt.
Ist das Feld Erweiterter Zeichensatz nicht gesetzt wird das Zeichen & automatisch zu + konvertiert, alle anderen Zeichen werden durch ein Leerzeichen ersetzt. |
| Bisher wurden beim Erstellen der Zahlungsdatei alle 8 Stelligen SWIFT-Codes mit XXX ergänzt.
Ab jetzt werden SWIFT-Codes des eigenen Bankkontos nicht mehr mit XXX ergänzt.
SWIFT-Codes des Externen Bankkontos werden nur mehr mit XXX ergänzt wenn das neue Feld Externen SWIFT-Code mit XXX ergänzen in der Zahlungsverkehr Einrichtung gesetzt ist. |
Bei SEPA bzw. XML Transaktionen mit Avis wurde in der Zahlungsdatei der Hinweistext See Notification gefolgt von der Avisnr. geschrieben.
Bei EDIFACT und MT101 Zahlungen ist der Text abhängig vom ISO Ländercode des Externen Bankkontos. Bei AT, DE und CH wird hier Siehe Avis gefolgt von der Avisnr. geschrieben.
Diese Logik ist jetzt auch bei SEPA bzw. XML Zahlungen aktiv.
Weiters kann der Text jetzt auch im Menü Zahlungsverkehr unter Einrichtung im Avis Text im Feld Zahlungsdateitext hinterlegt werden. Wird kein Avis Text gefunden, oder ist das Feld leer wird der Text über die vorher beschriebene Logik ermittelt.
Der Zahlungsdateitext kann je nach Sprachcode hinterlegt werden.
Es wird versucht den Sprachcode für den Avis Text folgendermaßen zu ermitteln:
- Über den Sprachcode des Debitors
- Alternativer Sprachcode
Es wird also zuerst versucht einen Textbaustein mit dem Sprachcode des Debitors zu finden.
Wurde für den Sprachcode des Debitors kein Textbaustein gefunden wird mit dem Alternativer Sprachcode Zahlungsverkehr, welcher jedem Sprachcode zugeordnet werden kann, gesucht.
Das wird nur dann gemacht wenn der Debitor einen Sprachcode angegeben hat.
Hat der Debitor keinen Sprachcode hinterlegt, wird nach Textbausteinen ohne Sprachcode gesucht.
Hat der Debitor einen Sprachcode hinterlegt, für diesen wurde aber kein Textbaustein gefunden und der Alternativer Sprachcode Zahlungsverkehr ist leer wird ebenfalls nach Textbausteinen ohne Sprachcode gesucht. |
| Das Feld Durchführungsdatum wurde aus den Clearingposten entfernt da das Datum nicht mehr auf dieser Ebene eindeutig ist. |
| Das Feld Empfängerreferenz im Zahlungsposten wurde auf 35 Stellen gekürzt und wird nur mehr bei Zahlungsart Inlandsüberweisung (PAYMUL), Lastschrift (DIRDEB) und Auslandsüberweisung (PAYMUL) befüllt. |
| Das Feld Avis Anzahl gedruckt im Zahlungsposten wurde in Avis gedruckt umbenannt. Das Feld wurde in ein Ja/Nein Feld geändert und zeigt jetzt an ob ein Avis gedruckt wurde oder nicht. |
| Es wurden allgemein die Meldungen, Fehlermeldungen und Captions verbessert. |
Alle für die Updates benötigten Dateien können hier heruntergeladen werden:
NAV_NCP_Update_20220525.zip
