NCP Zahlungsverkehr (NAV)

Hinweis

NCP Zahlungsverkehr ist für Microsoft Dynamics 365 Business Central unter dem Produktnamen NAVAX Payment Exports und NAVAX Payment Imports als Erweiterung verfügbar. Weitere Informationen dazu finden Sie unter [Docs] NAVAX Zahlungsverkehr

Handbuch

☰ Inhaltsverzeichnis

Anhang

• NAVAX Registrierung
  Der aktuelle Registrierungstatus eines NAVAX Dynamics NAV AddOns wird in der Einrichtung des AddOns unter System angezeigt...
• Versionshinweise
• Upgrade auf Business Central
  Dieses Thema richtet sich an Entwickler und beschreibt, welche Schritte notwendig sind, um die Daten aus der alten C/AL-Version (NAV AddOn) in die neue AL-Version (BC Extension) zu übernehmen...

Docs  /  NCP Zahlungsverkehr (NAV)  /  Anhang
NAVAX Registrierung

Testversion

Registrierung beantragen

Hinweis

Für die Registrierung, den Aufruf der Onlinehilfe und das Ausführen einiger Aktionen muss der Zugriff auf https://www.nccube.com und https://www.navax.app erlaubt sein. Zusätzlich ist TLS 1.2 erforderlich. Weitere Informationen dazu finden Sie unter How to get earlier versions of the Dynamics NAV development environment to work with TLS 1.2 Public IP von www.navax.app für die Freischaltung an der Firewall: 94.136.22.236, Port: TCP/443 Prüfung der Verbindung zu https://www.navax.app mittels PS: Test-NetConnection navax.app -port 443 (PS muss mit dem M-Tier Service-User ausgeführt werden) CRL-Server Zusätzlich müssen für die Zertifikatsprüfung auch folgende CRL-Server erreichbar sein: https://certificates.godaddy.com/* http://crl.godaddy.com/* oder deren IP: 192.124.249.36

Registrierung aktivieren/aktualisieren

AGB & EULA

https://www.navax.app/EULA.php?L=de

Datenschutz

https://www.navax.app/privacyStatement.php?L=de

Docs  /  NCP Zahlungsverkehr (NAV)  /  Anhang
Versionshinweise

Hinweis

NCP Zahlungsverkehr ist für Microsoft Dynamics 365 Business Central unter dem Produktnamen NAVAX Payment Exports und NAVAX Payment Imports als Erweiterung verfügbar. Weitere Informationen dazu finden Sie unter [Docs] NAVAX Zahlungsverkehr

NCP Update

NCP 13.01

• Hinweis

  Diese Version ist auch als Downgrade-Version für ältere Dynamics NAV Versionen verfügbar.

Änderungen

Zahlungsverkehr Import – Die Zuordnung der Posten wurde deutlich verbessert. In Version NCP 13.00 wurde in der Zahlungsverkehr Import Einrichtung das Feld Belegnr. Zuordnungsgenauigkeit hinzugefügt. Die Option Unscharf (Inkl. Werte ohne Sonderzeichen) wurde noch einmal überarbeitet und sollte jetzt ein deutlich besseres Ergebnis liefern.

Fehlerbehebungen

Die Einstellungen für die Dateinamen der Zahlungsdateien wurden ignoriert.

NCP 13.00

Allgemein

Ein Update der Lizenzdatei ist erforderlich.

Update Codeunits sind verfügbar. Wichtig Zahlungsverkehr Postenbemerkungen für Bankposten, Clearingposten, Zahlungsposten und Verwendungsposten wurden entfernt und werden nicht mehr unterstützt. Bei Bedarf muss diese Funktionalität über eine Individualprogrammierung umgesetzt werden. Bei einem Update werden die Daten in der Tabelle 1001702 NCP Entry Comment Line gelöscht.

Eine Registrierung ist jetzt erforderlich. Die Testversion läuft in 30 Tagen ab. Weitere Informationen dazu finden Sie unter Anhang, NAVAX Registrierung.

Verbesserungen

NC Payments unterstützt jetzt auch den Web Client und den Tablet Client. NC Payments ist jetzt auch für Microsoft Dynamics 365 Business Central – OnPremises verfügbar. Eine vollständige Liste aller verfügbaren Versionen finden Sie im Dokument Versionsmatrix. Beachten Sie, dass der Funktionsumfang bzw. die Funktionalität der Lösung abhängig von der installierten Version, dem von Ihnen verwendeten Client und/oder Ihrem Lizenzmodell variieren kann.

In der Zahlungsverkehr Export Einrichtung wurde die Funktion Daten löschen hinzugefügt. Durch das Erstellen einer Zahlungsdatei wird ein Eintrag in den Clearingposten erstellt.Die erstellte Zahlungsdatei wird ebenfalls dort gespeichert. Mit dieser Aktion können, falls notwendig, die archivierten Zahlungsdateien aus den Clearingposten entfernt werden. Hinweis Die Dateien können danach nicht mehr exportiert werden. Der Zeitraum für das Löschen der Daten kann in der Zahlungsverkehr Export Einrichtung im Feld Daten löschen Datumsformel angegeben werden. Es können nur Daten gelöscht werden, welche mindestens 6 Monate alt sind. Ist das Feld leer, wird der Mindestzeitraum verwendet.

In der Zahlungsverkehr Import Einrichtung wurde die Funktion Daten löschen hinzugefügt. Durch das Importieren einer Datei wird ein Eintrag im Zahlungsverkehr Import erstellt. Die importierte Datei wird ebenfalls dort gespeichert. Mit dieser Aktion können, falls notwendig, die archivierten Importdateien aus dem Zahlungsverkehr Import entfernt werden. Hinweis Der Zeitraum für das Löschen der Daten kann in der Zahlungsverkehr Import Einrichtung im Feld Daten löschen Datumsformel angegeben werden. Es können nur Daten gelöscht werden, welche mindestens 6 Monate alt sind. Ist das Feld leer, wird der Mindestzeitraum verwendet.

In der Zahlungsverkehr Export Einrichtung wurde für die Dateinamen der Platzhalter %10 Zahlungsart hinzugefügt.

In den Zahlungsverkehr XML Schemata wurde der Parameter/Wert [BankName2] hinzugefügt. Damit kann z.B. in Schemata der Art Non-SEPA Überweisung im Bereich CdtrAgt der Name des Bankkontos angegeben werden. Um sicherzustellen, dass alle neuen Schema Funktionen zur Verfügung stehen, müssen Sie die XML Schemata aktualisieren.

In den Zahlungsverkehr Import Fixe Kontozuordnungen wurde eine neue Option Transaktionscode im Feld Suche in hinzugefügt.

In der Zahlungsverkehr Import Einrichtung wurde Feld Belegnr. Zuordnungsgenauigkeit hinzugefügt. Die beiden Optionen beeinflussen die automatische Zuordnung der Debitorenposten. Die Option Scharf (Identischer Wert) entspricht der bisherigen Suche. Ist die Option Unscharf (Inkl. Werte ohne Sonderzeichen) gewählt, wird bei Debitoren zuerst (wie bei Scharf) nach dem exakten Wert der Belegnr. vom Debitorenposten gesucht. Danach wird, falls nichts gefunden wurde, nach der Belegnr. ohne folgende Sonderzeichen gesucht: !"§$%&/=?+-.,;#~*|<>({[]}) Beispiel: Im Verwendungszweck der Transaktion steht der Wert 'RE2804' In NAV steht im Debitorenposten die Belegnr. 'RE-2804' Bei der Suche wird für alle offenen Debitorenposten nach einer möglichen Transaktion gesucht. Mit unscharf wird also zuerst nach 'RE-2804' gesucht. Da keine Transaktion mit diesem Wert vorhanden ist, wird danach mit 'RE2804' gesucht. Dieser Wert wird im Verwendungszweck der Transaktion gefunden. Hinweis Da die unscharfe Zuordnung nicht so stark ist wie eine Scharfe, wird in diesem Fall die Belegwertung um 10 Punkte verringert.

Beim Import einer CAMT Datei wird das Buchungsdatum der Transaktion jetzt auch erkannt, wenn es im Format 'BookgDt DtTm' angegeben ist. Bisher wurde nur 'BookgDt Dt' berücksichtigt.

Beim Import einer CAMT Datei wird das Valutadatum der Transaktion jetzt auch erkannt, wenn es im Format 'ValDt DtTm' angegeben ist. Bisher wurde nur ' ValDt Dt' berücksichtigt.

Änderungen

Durch das Erstellen einer Zahlungsdatei wird, wie bisher, ein Eintrag in den Clearingposten erstellt. In der abschließenden Zusammenfassung werden jetzt alle Informationen zum erstellten Clearingposten angezeigt. Die Zahlungsdatei kann in der Zusammenfassung über Zahlungsdatei exportieren für die Banksoftware bereitgestellt werden. Hinweis Die Datei kann auch zu einem späteren Zeitpunkt über die Clearingposten exportiert werden.

Die Performance der Funktion Zahlungsdatei erstellen wurde deutlich verbessert. Zusätzlich wurde das Statusfenster überarbeitet.

Die Performance der Funktion Zahlungsdatei annullieren wurde deutlich verbessert. Zusätzlich wurde das Statusfenster überarbeitet.

Die von NC Payments in Version 6.12 hinzugefügten Postenbemerkungen für Bankposten, Clearingposten, Zahlungsposten und Verwendungsposten wurden entfernt und werden nicht mehr unterstützt.

Das Design einiger Fenster wurde überarbeitet bzw. verbessert.

Fehlerbehebungen

Die von NC Payments in Version 8.10 hinzugefügten Parameter für die Angabe der Empfänger Adresse in den XML Schemata wurden in der Zahlungsdatei nicht befüllt.

Wurde das Feld Gegenkontozeile erstellen in der Zahlungsverkehr Export Einrichtung gesetzt, konnte es beim Buchen zu einem Fehler bei der Betragsprüfung der Buch.-Blattzeilen kommen.

Annullierte Zahlungsposten werden im Zahlungsverkehr Import jetzt nicht mehr berücksichtigt.

Bei der Übertragung vom Zahlungsverkehr Import in ein Buch.-Blatt konnte es beim Währungsfaktor zu einer Fehlermeldung kommen.

NCP 11.01

Fehlerbehebungen

Aufgrund eines Objekt-ID Konflikts mit dem AddOn NC Kostenrechnung mussten die Pages mit der ID 1001750, 1001751 und 1001752 verlegt werden. Bevor die Objekte der Version NCP 11.01 importiert werden können, müssen folgende Objekte gelöscht werden: Page 1001750 NCP Country/Region Setup Page 1001751 NCP Bank Account Setup Page 1001752 NCP Bank Account Setup Card

NCP 11.00

Verbesserungen

NC Payments ist jetzt auch für Microsoft Dynamics NAV 2018 verfügbar.

Ab Microsoft Dynamics NAV 2018 sind Mitarbeiterzahlungen über NC Payments möglich.

In den Zahlungsverkehr Import Transaktionen wurde das Feld Externer Kontoinhaber Adresse hinzugefügt.

In der Zahlungsverkehr Import Einrichtung wurde das Feld Übertr. Spesen hinzugefügt. Wird das Feld auf Ja gesetzt, werden die Spesen ebenfalls in das Buch.-Blatt bzw. die Bankkontoabstimmung übertragen. Anmerkung: Es werden nur die Summe Spesen Zeilen übertragen. Das Spesenkonto für die direkte Übertragung in ein Buch.-Blatt bzw. die indirekte Übertragung in ein Buch.-Blatt über die Bankkontoabstimmung kann in der Zahlungsverkehr Bankkontoeinrichtung pro Bankkonto hinterlegt werden. Das neue Feld Import Herkunftsart in den Buch.-Blattzeilen bzw. in den Bankkontoabstimmungszeilen zeigt an, ob die Zeile eine Transaktion, Spesen, oder eine Bankkontoabstimmungszeile ist. Die Felder Zahlungsverkehr Import und Bankkontoabstimmung in den Buch.-Blattzeilen sind dadurch überflüssig und wurden entfernt.

In den Zahlungsverkehr Import Transaktionen wird bei camt Dateien jetzt der Währungsfaktor mitberücksichtigt. Wird die Transaktionszeile in ein Buch.-Blatt übertragen, wird der Auftragsbetrag bei Fremdwährungen jetzt mit dem korrekten Währungsfaktor umgerechnet.

In den Zahlungsverkehr XML Schemata wurde der Parameter/Wert [BankCcy] hinzugefügt. Damit kann in Schemata der Art Non-SEPA Überweisung im Bereich der Währungscode des Bankkontos angegeben werden. Um sicherzustellen, dass alle neuen Schema Funktionen zur Verfügung stehen, müssen Sie die XML Schemata aktualisieren.

Über die Aktion Externe Bankkontokarte in den Buch.-Blättern kann jetzt auch eine Einmalanweisung angelegt werden. Die Aktion Einmalanweisung in den Buch.-Blättern ist dadurch überflüssig und wurde entfernt.

Im Fenster der Einmalanweisung wurde die Aktion Daten vorschlagen hinzugefügt. Damit können die Daten der letzten Einmalanweisung (mit selber Kontoart/Kontonr.) vorgeschlagen werden. Da bisher die dafür notwendigen Daten nicht gespeichert wurden, bringt die Aktion erst dann Werte, wenn für die Kombination aus Kontoart und Kontonr. eine Zahlungsdatei mit der aktuellen Version erstellt wurde. Wird also z.B. eine Einmalanweisung bei einer Zeile der Art=Sachkonto hinterlegt und anschließend eine Datei erstellt, können diese Daten für die Einmalanweisung auf dasselbe Sachkonto beim nächsten Mal vorgeschlagen werden.

Änderungen

Das Hauptmenü wurde überarbeitet.

Das Design einiger Fenster wurde überarbeitet.

Die Zahlungsverkehr Einrichtung wurde umbenannt zu Zahlungsverkehr Export Einrichtung.

Alle NC Payments Erweiterungen/Änderungen der Währungen, Länder/Regionen und Sprachen wurden aus den Standardobjekten entfernt und in eigene Objekte ausgelagert. Die Einrichtung erfolgt wie bisher über die Zahlungsverkehr Export Einrichtung bzw. über die Zahlungsverkehr Import Einrichtung und der entsprechenden Aktion. Die Felder Mandantenwährungscode und ISO Mandantenwährungscode wurden aus der Zahlungsverkehr Export Einrichtung und aus der Zahlungsverkehr Import Einrichtung entfernt. Richten Sie stattdessen für den ISO Code der Mandantenwährung (normalerweise EUR) einen Datensatz ohne Währungscode im neuen Fenster Zahlungsverkehr Währungseinrichtung ein.

Alle Zahlungsverkehr Felder wurden aus dem Bankkonto entfernt und in das neue Objekt Zahlungsverkehr Bankkontoeinrichtung ausgelagert. Die Einrichtung erfolgt über die Zahlungsverkehr Export Einrichtung bzw. über die Zahlungsverkehr Import Einrichtung und der Aktion Bankkonto.

Die Zahlungsverkehr Import Buchungszeilen und alle dazugehörigen Felder und Aktionen wurden umbenannt zu Zahlungsverkehr Import Transaktionen.

Im Zahlungsverkehr Import werden Felder und Aktionen für das Übertragen in ein Buch.-Blattzeilen bzw. in die Bankkontoabstimmung nur mehr angezeigt, wenn diese auch in der Zahlungsverkehr Import Einrichtung eingerichtet wurden. Ist z.B. keine Übertragung in eine Bankkontoabstimmung vorgesehen/eingerichtet, werden die dafür notwendigen Felder und Aktionen auch nicht mehr angezeigt.

Das Feld Übergreifende Spesen in den Zahlungsverkehr Import Spesen wurde umbenannt zu Summe Spesen.

Die Avis Texte und die SEAP Mandatstexte werden jetzt zentral über das Fenster Zahlungsverkehr Spracheinrichtung eingerichtet. Die Zahlungsverkehr Spracheinrichtung kann über die Zahlungsverkehr Export Einrichtung und der Aktion Sprachen aufgerufen werden. Über die Aktion Daten initialisieren können Werte für die Einrichtung vorgeschlagen werden. Hinweis: In den meisten Fällen ist bei den Kreditoren und Debitoren kein Sprachcode hinterlegt. Richten Sie deshalb zusätzlich einen Datensatz ohne Sprachcode ein. Über das Feld Verknüpfter Sprachcode ist es möglich, Texte aus einem anderen Sprachcode zu verlinken. D.h. der Text wird nicht beim aktuellen Sprachcode eingerichtet, sondern beim verknüpften Code. Nachfolgend ein Beispiel einer möglichen Einrichtung:

Fehlerbehebungen

Fehlende Übersetzungen in den Captions wurden ergänzt.

Bei der Prüfung des Zahlungsstatus der Funktion Belegnummern neu nummerieren im Buch.-Blatt wurden auch Zeilen aus anderen Buch.-Blättern geprüft.

Wurde der Zahlungsvorschlag mit der der Option Pro Kreditor/Debitor summieren aufgerufen, blieb das Feld Ausgleichs-ID in einigen Posten gesetzt, falls der Vorschlag mit einer Fehlermeldung abbrach. Der Fehler tritt auch im Standard auf. Der Fehler wurde durch eine geänderte Aufruf-Logik behoben.

NCP 10.01

Änderungen

Die Registrierung ist ab jetzt an den Tenant gebunden.

Die Support E-Mail Funktionalität wurde überarbeitet und ist jetzt über What's New? verfügbar.

NCP 10.00

Verbesserungen

Im Fenster Zahlungsverkehr Einrichtung wurde die Funktion Support E-Mail hinzugefügt. Sollten Probleme/Fragen bezüglich des AddOns auftreten, verwenden Sie bitte diese Funktion. Die dabei geöffnete E-Mail enthält Informationen, welche bei der Problemlösung hilfreich sind.

Die Zahlungsdatei-Einstellungen in der Zahlungsverkehr Einrichtung können jetzt pro Bankkonto unterschiedlich eingestellt werden. Bei der Erstellung der Zahlungsdatei wird zuerst nach der Einstellung für das Bankkonto gesucht. Ist keine spezielle Einstellung vorhanden, wird wie bisher die Einstellung ohne Bankkontoangabe verwendet.

Die Zahlungsverkehr XML Schemata können jetzt bearbeitet, bzw. neu angelegt werden.

Bei Einmalanweisungen wurden bisher die Empfängerdaten (Name, Adresse) direkt vom Kreditor/Debitor in die Zahlungsdatei geschrieben. Ab jetzt können abweichende Empfängerdaten in der Einmalanweisung angegeben werden. Wird nichts angegeben werden die Daten wie bisher ermittelt.

Die Bankkontosuche im Zahlungsverkehr Import suchte bis jetzt nur mit der Kombination aus IBAN und SWIFT-Code. Ab jetzt wird, falls kein Bankkonto gefunden wurde, zusätzlich auch nach dem IBAN ohne den SWIFT-Code gesucht.

Änderungen

Für die Nutzung einiger Online-Dienste ist eine Registrierung erforderlich. Weitere Informationen dazu finden Sie unter Anhang, NAVAX Registrierung.

Das Design der Bankcodes wurde überarbeitet bzw. verbessert. Klicken Sie im Fenster Zahlungsverkehr Einrichtung auf Bankcodes und anschließend auf Download…. Wählen Sie die Option Anlegen & vorhandene Datensätze überschreiben um die Codes zu aktualisieren. Alternativ können Sie auch vor dem Download alle Bankcodes löschen. Der Vorteil dabei ist, dass der Inhalt der Tabelle nach dem Download dem aktuellen Stand für Österreich und Deutschland entspricht. Manuell angelegte Daten gehen dabei allerdings verloren.

Im Zahlungsvorschlag wurde das Ergebnis bei einer Kombination verschiedener Optionen (z.B. Skonto finden oder Verfügbarer Betrag (MW)) verbessert bzw. optimiert.

Im Import-Bereich wurde die Funktionalität Ausgleich vorschlagen (Buch.-Blatt.) bzw. Automatisch abgleichen (Bankkontoabstimmung) signifikant verbessert bzw. optimiert. Das Analysefenster wurde ebenfalls verbessert und zeigt jetzt genauere Informationen zum Auswahlverfahren an. Zusätzlich kann das Fenster jetzt mit OK geschlossen werden. Dadurch wird der Vorschlag in das Buch.-Blatt bzw. die Bankkontoabstimmung übernommen und nicht wie bisher verworfen. Grundsätzlich wird aber weiterhin empfohlen, das Fenster nur für Analysezwecke zu aktivieren. Grund dafür ist, dass zum Zeitpunkt der Bestätigung mit OK nicht mehr garantiert werden kann, ob noch alle Posten für den Ausgleich verfügbar und offen sind. Es kann dabei also zu einer Fehlermeldung bzw. zu einem Hinweis kommen, dass ein anderer Anwender Daten geändert hat, bzw. dass der Ausgleich nicht mehr gesetzt werden kann.

Das Design einiger Fenster wurde überarbeitet bzw. verbessert.

Fehlerbehebungen

Wurde im Buch.-Blatt der Ausgleich geändert, nachdem die Zahlungsdatei erstellt wurde, konnte es zu einer Fehlermeldung kommen. Das Fenster konnte dabei nicht mehr geschlossen werden und ein Neustart des Clients war notwendig.

War das Feld Änderung nach "Datei erstellt" zugelassen in der Zahlungsverkehr Einrichtung nicht gesetzt, konnte es in Verbindung mit Einmalanweisungen beim Buchen im Buch.-Blatt zu einer Fehlermeldung kommen.

Der Avis konnte in der Classic-Umgebung von NAV 2009 nicht per E-Mail gesendet werden.

camt-Dateien, bei denen Boolean-Felder auf die Werte '0' und '1' statt 'TRUE' und 'FALSE' gesetzt sind, konnten nicht importiert werden.

Beim Import von benutzerdefinierten Dateien wurde kein Bankkonto vorgeschlagen.

Beim Import von benutzerdefinierten Dateien wurden die Felder Zusatzinformation und Verwendungszweck nicht befüllt.

Aufgrund der Tatsache, dass sich nicht alle Banken strikt an die MT940 Spezifikation halten, wurden XML-Bezeichner (z.B. EREF, SVWZ) bei Längenüberschreitung teilweise mit falschen Werten belegt. Ab sofort wird bei KREF, EREF, PREF und MREF keine Längenüberschreitung mehr berücksichtigt da bei diesen Feldern aufgrund der maximalen Zeichenanzahl ohnehin keine Überschreitung möglich ist. Für die restlichen Bezeichner wird eine Längenüberschreitung nur mehr dann berücksichtigt, wenn man das neue Feld MT940 - Geteilte XML Bezeichner im Fenster Zahlungsverkehr Import Einrichtung setzt.

NCP 8.10

Verbesserungen

Im Zahlungsausgangs Buch.-Blatt und im Zahlungseingangs Buch.-Blatt wurde ein neues Feld Sammeltransaktionsnr. hinzugefügt. Das Feld ist standardmäßig ausgeblendet. Abhängig von der Einstellung im Feld Sammeltransaktion der Zahlungsverkehr Einrichtung, Register Zahlungsdatei, gibt es 2 unterschiedliche Funktionsweisen: Sammeltransaktion in der Zahlungsverkehr Einrichtung = Nein Es werden (wie bisher) bei der Dateierstellung keine Buch.-Blattzeilen zusammengefasst. Mit Hilfe des neuen Feldes Sammeltransaktionsnr. ist es jetzt aber möglich, Ausnahmen für einzelne Zeilen zu definieren. Zeilen mit selber Sammeltransaktionsnr. werden zusammengefasst. Zeilen ohne Sammeltransaktionsnr. werden nicht zusammengefasst. Sammeltransaktion in der Zahlungsverkehr Einrichtung = Ja Es werden (wie bisher) bei der Dateierstellung alle Buch.-Blattzeilen zusammengefasst. Mit Hilfe des neuen Feldes Sammeltransaktionsnr. ist es jetzt aber möglich, Ausnahmen für einzelne Zeilen zu definieren. Zeilen mit selber Sammeltransaktionsnr. werden zusammengefasst. Zeilen ohne Sammeltransaktionsnr. werden ebenfalls zusammengefasst. Für beide Fälle gilt: Unabhängig von den Einstellungen in der Zahlungsverkehr Einrichtung und im Feld Sammeltransaktionsnr. werden Zeilen, bei denen eine Zahlungsreferenz angegeben wurde, oder Einmalanweisungszeilen, immer einzeln exportiert. Weiters werden nur Zeilen zusammengefasst, bei denen folgende Felder dieselben Wert enthalten: Zahlungsart Kontoart Kontonr. Externer Bankkontocode Währungscode Lastschriftart Lastschriftfrequenz Mandat ID Mandat erteilt am Daraus ergibt sich, dass ein und dieselbe Sammeltransaktionsnr. durchaus mehrfach vergeben werden kann. Bsp.: Debitor A hat eine Zahlung und eine Gutschrift, für beide Zeilen wird Sammeltransaktionsnr. = '1' angegeben. Debitor B hat 3 Zahlungen, auch hier wird für alle 3 Zeilen Sammeltransaktionsnr. = '1' angegeben. Es werden trotz selber Sammeltransaktionsnr. zwei separate Transaktionen in die Zahlungsdatei geschrieben.

Zum Bankkonto wurden die neuen Felder Auftraggeber ID und Herausgeber der Auftraggeber ID hinzugefügt. In XML Zahlungsdateien wurde bisher für die Auftraggeber-Identifikation nur der Name des Auftraggebers aus der Zahlungsverkehr Einrichtung verwendet. In einigen Ländern bzw. einige Banken verlangen zusätzlich noch eine ID für die eindeutige Identifikation. Diese ID kann jetzt am Bankkonto hinterlegt werden und wird, bei der Erstellung von XML Zahlungsdateien für dieses Bankkonto, in die Datei geschrieben.

In den XML Schemata wurde das Feld Adressangabe möglich hinzugefügt. Das Feld zeigt an, ob das Schema Adressdaten unterstützt. Ist Adressangabe möglich, können die Felder Auftraggeber Adresse und Empfänger Adresse gesetzt werden. Ist Auftraggeber Adresse gesetzt, werden die Adressdaten des Auftraggebers, welche in der Zahlungsverkehr Einrichtung hinterlegt wurden, in die Zahlungsdatei geschrieben. Ist Empfänger Adresse gesetzt, werden die Adressdaten des Kreditors/Debitors in die Zahlungsdatei geschrieben. Um sicherzustellen, dass alle neuen Schema Funktionen zur Verfügung stehen, müssen Sie die XML Schemata aktualisieren.

Beim Import/Download der XML Schemata wurde eine neue Option Anlegen & vorhandene Datensätze aktualisieren (Einstellungen beibehalten) hinzugefügt. Wird diese Option ausgewählt, gehen die Einstellungen (z.B. IBAN Only Ausland, Sammelbuchung, Erweiterter Zeichensatz usw.) für die einzelnen Schemata durch die Aktualisierung nicht mehr verloren.

In der Zahlungsverkehr Import Einrichtung wurde ein neues Feld Übertr. Betrag hinzugefügt. Dieses Feld wird nur bei der Übertragung in ein Buch.-Blatt berücksichtigt. Ist die Option Auftragsbetrag/Buchungsbetrag ausgewählt, wird, falls vorhanden, der Auftragsbetrag in das Buchblatt übertragen. Ansonsten wird der Buchungsbetrag übertragen. Ist die Option Buchungsbetrag ausgewählt, wird nur der Buchungsbetrag berücksichtigt bzw. übertragen.

Die Postensuche des Zahlungsverkehr Imports wurde erweitert. Es wird jetzt zusätzlich nach Zahlungsreferenzen innerhalb des Verwendungszwecks gesucht.

Bei der Auswahl eines Sachkontos in Zahlungsverkehr Import Fixe Kontozuordnungen wird jetzt geprüft, ob das Konto in einem Buch.-Blatt verwendet werden darf.

Der Zahlungsverkehr Import wurde um den Punkt Benutzerdefinierte Formate erweitert. Mit Hilfe von benutzerdefinierten Formaten ist es möglich, Kontoauszüge im CSV Dateiformat in den Zahlungsverkehr Import einzulesen. Es können beliebig viele Formate definiert werden. Für jedes Format kann der Dateiaufbau (Trennzeichen, Felder und Feldformate) festgelegt werden. Einschränkungen / Vorgaben: Die Datei muss mit einer Zeile, welche die Feldnamen beinhaltet (Header), beginnen. Eine Zeile bzw. ein Datensatz darf nicht länger als 1024 Zeichen sein. Nach der Anlage eines Formats und der Einrichtung der Trennzeichen welche in der CSV Datei verwendet werden, können die Felder der Datei und deren Zuordnung zum Zahlungsverkehr Import eingerichtet werden. Mit Hilfe der Funktion Felder vorschlagen können die Felder automatisch aus der CSV Datei bzw. der Zeile, welche die Feldnamen beinhaltet (Header), ausgelesen bzw. vorgeschlagen werden. Jedes Feld der Datei, welches in den Zahlungsverkehr Import eingelesen werden soll, muss anschließend einer Feldnummer des Imports zugeordnet werden.

Ab Microsoft Dynamics NAV 2013 R2 gibt es im Standard die Möglichkeit eine Zahlungsreferenz in der Tabelle Einkaufskopf anzugeben. Diese Zahlungsreferenz wird jetzt beim Buchen in das Feld Zahlungsreferenz des NC Zahlungsverkehrs der Kreditorenposten geschrieben. Sollte der Text aus dem Standard Feld (max. 50 Zeichen) länger sein als das NC Zahlungsverkehr Feld (max. 35 Zeichen) wird der Inhalt abgeschnitten und es erscheint eine Hinweismeldung.

Änderungen

Das Feld Creditor ID in der Zahlungsverkehr Einrichtung wurde umbenannt zu Creditor Identifier (CI).

Zahlungsverkehr Import Fixe Kontozuordnungen können jetzt nicht mehr Importiert/Exportiert werden.

Es wurden Anpassungen für eine einfachere Lizensierung von NC Payments durchgeführt.

Fehlerbehebungen

Im Zahlungsvorschlag für Kreditoren und Debitoren wurden nach dem eigentlichen Vorschlag zusätzlich noch einmal die Kreditoren- bzw. Debitorenposten gelesen. Dies konnte in gewissen Konstellationen zu Performance-Einbußen führen.

Im Zahlungsvorschlag wurde bei Überweisungen ein Fehler in Verbindung mit der Option Verfügbarer Betrag (MW) korrigiert.

NCP 8.00

Verbesserungen

Der Zahlungsvorschlag – Kreditoren bzw. der Zahlungsvorschlag – Debitoren wurde um die Möglichkeit erweitert, Filter auf Postenebene anzugeben. Mit Hilfe dieser Filter kann der Vorschlag zusätzlich eingeschränkt werden. Filter, welche intern vom Vorschlag gesetzt werden, sind weiterhin gültig und können dadurch nicht aufgehoben werden. Eine Einschränkung ist allerdings möglich. Wird z.B. der Filter 'USD' im Feld Währungscode angegeben und im Feld Zahlungsart Inlandsüberweisung (PAYMUL) ausgewählt, wird der Vorschlag kein Ergebnis liefern, da der Vorschlag nur Währungen mit ISO Code 'EUR' berücksichtigt, zusätzlich aber der Filter auf 'USD' gesetzt wurde. Bei Zahlungsart Auslandsüberweisung (PAYMUL) würden in diesem Fall nur Zeilen mit Währungscode 'USD' vorgeschlagen.

Ist das Feld Gegenkontozeile erstellen aus der Zahlungsverkehr Einrichtung gesetzt, wird bei der Erstellung der Zahlungsdatei in gewissen Konstellationen (siehe NCP 7.10) die Belegart bei einzelnen Buch.-Blattzeilen geändert. Diese Änderungen werden jetzt gespeichert. Wird die Transaktion annulliert, wird die Belegart wieder auf den ursprünglichen Wert zurückgesetzt.

In den XML Schemata wurde das Feld IBAN oder Kontonummer möglich hinzugefügt. Das Feld zeigt an, ob das Schema Transaktionen ohne IBAN unterstützt. Ist IBAN oder Kontonummer möglich kann das Feld IBAN oder Kontonummer gesetzt werden. Ist IBAN oder Kontonummer gesetzt wird der Inhalt des Feldes Kontonummer in die Zahlungsdatei geschrieben falls kein IBAN vorhanden ist. (Anmerkung: der IBAN im eigenen Bankkonto muss immer angegeben werden) Um sicherzustellen, dass alle neuen "XML Schema" Funktionen zur Verfügung stehen, müssen Sie die "XML-Schemata" aktualisieren.

Die Zahlungsstatistik wurde erweitert und zeigt jetzt Beträge pro Zahlungsart, Bankkontonummer und Währungscode an. Die Gesamtsummen im Register Allgemein wurden ebenfalls angepasst.

Wird die Zahlungsverkehr Einrichtung das erste Mal geöffnet, werden ab jetzt folgende Felder vorbelegt: ISO Mandantenwährungscode wird bei Mandantenwährungscode = 'EUR' oder 'EURO' mit 'EUR' vorbelegt. Auftraggeber: Name, Name 2 und Adressdaten werden aus den Firmendaten vorgeschlagen. Zahlungsdatei: Im Verwendungszweck Feld wird der Wert '/[/%2][/%5%6][/Disc%7]' vorgeschlagen.

In der Zahlungsverkehr Einrichtung wurde im Register Avis ein neues Feld Avis Text vorhanden hinzugefügt. Dieses Feld zeigt an, ob Avis Text vorhanden ist. Mit AssistEdit im Feld kann die Einrichtung der Avis Texte geöffnet werden.

Die Felder Zahlungsdateitext und E-Mail Betreff werden bei der Anlage eines neuen Avis Text Datensatzes jetzt mit einem Vorschlagswert vorbelegt. Wird kein Sprachcode angegeben, werden die Felder in deutscher Sprache vorbelegt. Ist ein Sprachcode angegeben, werden die Felder in englischer Sprache vorbelegt.

In der Zahlungsverkehr Einrichtung wurden folgende Funktionen hinzugefügt: Avis Testnachricht senden Damit ist es möglich, die Einstellungen der Avis E-Mail Funktionalität zu testen. Wird die Funktion aufgerufen, muss im Feld Testnachricht an die E-Mail Adresse angegeben werden, an die die Avis Testnachricht gesendet werden soll. Zugriffsrechte erstellen Damit können die Standard Zahlungsverkehr Zugriffsrechtsätze (Rollen) erstellt bzw. aktualisiert werden. Währungen initialisieren Diese Funktion füllt das Feld ISO Code Zahlungsverkehr in der Tabelle Währung. Dabei wird für jeden verfügbaren ISO Code geprüft, ob eine Währung mit selben Code existiert. Ist das der Fall, wird geprüft, ob das Feld ISO Code Zahlungsverkehr einen Wert enthält. Ist noch kein Wert eingetragen, wird der ISO Code in das Feld geschrieben. Länder/Regionen initialisieren Diese Funktion füllt die Felder ISO Code Zahlungsverkehr und SEPA in der Tabelle Land/Region. Dabei wird für jeden verfügbaren ISO Code geprüft, ob ein Land/Region mit selben Code existiert. Ist das der Fall, wird geprüft, ob das Feld ISO Code Zahlungsverkehr einen Wert enthält. Ist noch kein Wert eingetragen, wird der ISO Code in das Feld geschrieben. Danach wird bei allen Ländern, welche aufgrund ihres ISO Codes SEPA angehören, das Feld SEPA gesetzt. Kreditor/Debitor Bankkonten exportieren und Kreditor/Debitor Bankkonten importieren Diese beiden Funktionen waren bis jetzt als Menüpunkte im Zahlungsverkehr unter Einrichtung, Bankkonten Export/Import aufrufbar. Im Hauptmenü wurden die Punkte entfernt und sind jetzt hier aufrufbar.

Im Zahlungsverkehr wurde eine neue Funktionalität für den Import von camt, MT940 und CREMUL hinzugefügt. Der bisherige MT940 Import wurde entfernt und ist nun Teil dieser neuen Funktionalität.

Änderungen

Wurden innerhalb einer XML Zahlungsdatei mehrere Zahlungen in einer XML Transaktion zusammengefasst, wurden die Verwendungszwecke der Transaktion automatisch mittels Komma voneinander getrennt. Diese Logik wurde entfernt.

Im Verwendungszweck der Zahlungsdatei werden jetzt die Tausendertrennzeichen der Betragsfelder (Betrifft Parameter %6 und %7) automatisch entfernt.

In der Zahlungsvorschlagsliste wurden in der Zusammenfassung die Vorzeichen der Beträge geändert.

Das Lookup-Verhalten der BLZ und SWIFT-Code Felder wurde verbessert.

Das Feld Bank Währungscode am Bankkonto wurde in Bank Währungscode (PAYMUL/DIRDEB) umbenannt.

Das Feld Eingebettete Zahlungsdatei speichern in der Zahlungsverkehr Einrichtung wurde in Zahlungsdatei archivieren umbenannt.

Das Feld Eingebettete Datei vorhanden in den Clearingposten wurde in Archivierte Datei vorhanden umbenannt.

NCP 7.12

Verbesserungen

In der Bankkontoabstimmung und am Bankkontoauszug wird jetzt auch der unstrukturierte Verwendungszweck angezeigt.

Fehlerbehebungen

In der Bankkontoabstimmung und am Bankkontoauszug wurden im Feld Verwendungszweck keine Werte angezeigt.

NCP 7.11

Fehlerbehebungen

Die von Microsoft in Version NAV 2013 R2 neu hinzugefügte Funktion Belegnummern neu nummerieren, war fehlerhaft. Der Fehler wurde von Microsoft mit Cumulative Update 6 behoben. Hotfix ID: 357325 Hotfix Title: The Apply-to field on the Apply Vendor Entries page is not updated when you use the Renumber Document Numbers function on the Payment Journal page In NCP Version 7.10 wurde folgende Erweiterung hinzugefügt: Im Zahlungsausgangs Buch.-Blatt und Zahlungseingangs Buch.-Blatt wurde ein neuer Menüpunkt Belegnummern neu nummerieren im Button Funktion hinzugefügt. Die von NCP 7.10 hinzugefügte Funktion verwendet Teile von der von Microsoft zur Verfügung gestellten Funktion und ist in Folge dessen ebenfalls von dem Fehler betroffen. Da der Hotfix von Microsoft allerdings nur einen Teil der Fehler in diesem Zusammenhang behebt, hat NAVAX sich entschlossen, für die von NCP zur Verfügung gestellte Funktion Belegnummern neu nummerieren nicht mehr auf die von Microsoft zur Verfügung gestellte Funktion zurückzugreifen. NCP 7.11 behebt die Fehler laut Hotfix von Microsoft und weitere Fehler, welche in diesem Zusammenhang auftreten können, allerdings nur, für die von NCP zur Verfügung gestellte Funktion Belegnummern neu nummerieren. Die von Microsoft zur Verfügung gestellte Funktion wird nicht von NCP 7.11 verändert bzw. korrigiert.

Der Filter im Aufruf der Zahlungsposten über die Kreditorenkarte und über die Kreditorenübersicht war fehlerhaft.

Der Avis E-Mail Vorschlag brachte in gewissen Konstellationen nach dem Senden der E-Mail eine Fehlermeldung. Betroffen davon waren Versionen ab NAV 2009.

Wurde ein Avis per E-Mail gesendet, wurde das Feld Avis gedruckt im Zahlungsposten gesetzt. Betroffen davon waren Versionen ab NAV 2009.

NCP 7.10

Verbesserungen

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 '&lt;' > wurde zu '&gt;' & wurde zu '&amp;' " wurde zu '&quot;' ' wurde zu '&apos;' 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.

Fehlerbehebungen

Im Zahlungsvorschlag wurden bei Skonto finden in Verbindung mit Skontotoleranz berücksichtigen nicht alle zukünftigen Posten abgerufen. Wenn das Buchungsdatum des Zahlungsvorschlags zwischen dem Skontodatum und dem Skontotoleranzdatum des Postens lag und das Letzte Fälligkeitsdatum des Zahlungsvorschlags vor dem Skontotoleranzdatum lag wurde der Posten nicht abgerufen. Dies wurde korrigiert.

Die Ermittlung des Verwendungszwecks in der Zahlungsvorschlagsliste, im Avis und in den Verwendungszweckposten konnte in gewissen Konstellationen verwirrende Ergebnisse liefern. Das Problem trat in Verbindung mit Ausgleich mit Belegnr. auf wenn mehrere Buch.-Blattzeilen dieselbe Ausgleich mit Belegnr. verwendeten. In diesem Fall konnten die Verwendungszwecke nicht richtig berechnet werden. Dies hatte weder Auswirkung auf die Buchung noch auf die Beträge in der Zahlungsdatei. Allerdings war der Aufbau des Verwendungszwecks in diesem Fall etwas irreführend. Beispiel: Es existieren 2 offene Kreditorenposten, einmal mit 200 Euro, einmal mit 1000 Euro. Beide Posten haben dieselbe Belegnr.: XYZ. Nach dem Abruf des Zahlungsvorschlags erhält man 2 Buch.-Blattzeilen welche beide im Feld Ausgleich mit Belegnr. XYZ gesetzt haben. Beim Berechnen des Verwendungszwecks findet die erste Buch.-Blattzeile mit 200 Euro den ersten offenen Posten. Hier wird der Verwendungszweck richtig berechnet. Die 2. Buch.-Blattzeile mit 1000 Euro findet ebenfalls den ersten offenen Posten mit 200 Euro und geht beim Verwendungszweck davon aus das 200 Euro für den Posten verwendet werden und der Restbetrag von 800 Euro zusätzlich als Zahlung an den Kreditor gehen. Dies wurde korrigiert. Die Berechnung des Verwendungszwecks berücksichtigt jetzt eventuell vorhandene Buch.-Blattzeilen für die ebenfalls dieselbe Ausgleich mit Belegnr. gesetzt ist.

NCP 7.02

Verbesserungen

Im Zahlungsvorschlag wurde in den Optionen ein neues Feld Skontotoleranz berücksichtigen hinzugefügt. Ist dieses Feld gesetzt wird das Skontotoleranzdatum der Posten bei der Skontoberechnung mitberücksichtigt sofern auf der Kreditoren/Debitorenkarte nicht das Feld Zahlungstoleranz sperren gesetzt ist. Sollte zusätzlich das Feld Skonto finden im Zahlungsvorschlag gesetzt sein dann wird bei der Suche nach möglichen (zukünftigen) Zahlungen nicht nur auf das Skontodatum sondern auch auf das Skontotoleranzdatum gefiltert. Diese Erweiterung ist nicht für Objekte der Version NAV 3.60 verfügbar.

Bei der Erstellung des Zahlungsvorschlags werden nun in einem Fenster genauere Informationen über den aktuellen Fortschritt angezeigt.

Im Zahlungsverkehr gibt es nun die Möglichkeit Kreditor und Debitor Bankkonten in eine CSV Datei zu exportieren bzw. von dort später wieder zu importieren. Zu finden ist diese Funktionalität im Menü Zahlungsverkehr > Einrichtung > Bankkonten Export/Import. Mit der Funktion Bankkonten exportieren können die Bankkontodaten im Format: InternalType;InternalNo;InternalCode;BLZ;Bankkontonummer;SWIFT-Code;IBAN exportiert und danach zur Überarbeitung weitergegeben werden. Die Felder InternalType, InternalNo und InternalCode sollten dabei nicht verändert werden da die Informationen sonst beim Import nicht mehr korrekt zugeordnet werden können. Beim Export werden alle Leerzeichen der Felder BLZ, Bankkontonummer, SWIFT-Code und IBAN in der Datei entfernt. Mit der Funktion Bankkonten importieren können die überarbeiteten Bankkontodaten wieder importiert werden. In den Optionen des Imports wird über das Feld Vorhandene Werte festgelegt was beim Import mit bereits vorhandenen Werten passieren soll. Das Feld Vorhandene Werte besitzt folgende Optionen: Beibehalten und leere Felder ergänzen Damit werden nur Felder welche aktuell in der Datenbank leer sind aktualisiert. Überschreiben wenn neuer Wert vorhanden Damit werden unabhängig vom aktuellen Inhalt Felder in der Datenbank aktualisiert wenn in der Datei ein Wert eingetragen ist. Alle Überschreiben Damit werden alle Felder in der Datenbank mit denen der Datei überschrieben. Für alle Optionen gilt: Sollte sich der Feldinhalt in der Datenbank nicht vom Inhalt der Datei unterscheiden wird das Feld nicht verändert. Weiters gibt es beim Import über die Option Bankcodes erstellen noch die Möglichkeit die Bankcodes im Zahlungsverkehr anzulegen falls diese noch nicht vorhanden sind. Zusätzliche Anmerkungen: Es müssen nicht alle Daten exportiert werden. Beim Import werden auch nur jene Bankkontodaten in der Datenbank aktualisiert welche sich in der Datei befinden. Sollten Bankkontodaten im File existieren welche nicht mehr in der Datenbank vorhanden sind werden diese übersprungen.

MT940 Dateien der BAWAG P.S.K. können in den Subfeldern des Blocks 86 zusätzliche Informationen enthalten. Information der BAWAG P.S.K.: Aufgrund diverser Kundenanforderungen werden diese Spezifikationen als zusätzliches Service der BAWAG P.S.K. für die bessere Zuordnung diverser Zahlungen eingesetzt: /AIK/ Dabei handelt es sich um den Imagekey (AIK) gescannter Belege. AIK ist das Kennzeichen der Ersterfassungsreferenz bzw. Imagereferenz der Bank. /AES/ Dabei handelt es sich um einen Ausgangssammler mit Images. AES ist das Kennzeichen einer Bestandsreferenz bzw. Verdichterreferenz der Bank. Im Zahlungsverkehr werden diese Informationen nun in den neu hinzugefügten Feldern Ersterfassungsreferenz der Bank (AIK) bzw. Bestandsreferenz der Bank (AES) der MT940 Buchungszeilen gespeichert.

Änderungen

In NAV 2013 wurden im Standard Zahlungsvorschlag Prüfungen auf Kreditorenebene hinzugefügt welche Kreditoren von vornherein aufgrund des aktuellen Wertes im Feld Saldo (MW) vom Vorschlag ausschließen. Diese Prüfungen, welche mit NCP 7.00 in den Zahlungsverkehr übernommen wurden, wurden nun wieder entfernt bzw. deaktiviert da zu diesem Zeitpunkt noch nicht alle dafür notwendigen Informationen vorhanden sind. Es wurde dadurch z.B. der Inhalt des Feldes Abwarten in den Posten nicht berücksichtigt. Auch wurden Posten welche bereits in einem Buch.-Blatt zum Ausgleich vorgeschlagen sind nicht berücksichtigt.

Fehlerbehebungen

MT940 Dateien, welche im Block 86 im unstrukturierten Verwendungszweck die maximale Zeilenanzahl enthielten, konnten nicht eingelesen werden. Der MT940 Import brachte in diesem Fall die Fehlermeldung: Die angegebene Datei ist keine MT940 Datei.

Die Feldlängen und Relationen der Felder Benutzer-ID und Externe Belegnummer waren im Zahlungsverkehr Objektstand der Version NAV 2013 nicht korrekt.

NCP 7.01

Verbesserungen

Folgende Felder wurden im Zahlungseingangs Buch.-Blatt hinzugefügt: Bankeinzugsmethode SEPA Mandat ID SEPA Mandat erteilt am SEPA Bankeinzugsart Diese Felder werden bei der Eingabe des Feldes Externer Bankkontocode bzw. über den Zahlungsvorschlag befüllt und können im Buch.-Blatt bei Bedarf geändert werden. Das Feld Bankeinzugsmethode besitzt folgende Optionen: Basislastschrift (CORE) Firmenlastschrift (B2B) Einzugsermächtigung Abbuchungsauftrag Die Vorbelegung wird aufgrund der gewählten Zahlungsart (Bankeinzug (DIRDEB) oder SEPA Bankeinzug (SDD)) und der auf der Debitor Bankkontokarte hinterlegten Einstellung der Felder Bankeinzugsmethode (DIRDEB) bzw. SEPA Bankeinzugsmethode (SDD) ermittelt. Bei Zahlungsart = SEPA Bankeinzug (SDD) werden zusätzlich noch die Felder SEPA Mandat ID und SEPA Mandat erteilt am mit den Einstellungen aus der Debitor Bankkontokarte befüllt. Das Feld SEPA Bankeinzugsart besitzt folgende Optionen: Einmalig Wiederkehrend Erster Letzter Die Vorbelegung wird hier über die bereits gebuchten Zahlungsposten ermittelt. Wird für diesen Debitor und externen Bankkontocode ein Zahlungsposten gefunden welcher in den Feldern SEPA Mandat ID und SEPA Mandat erteilt am denselben Inhalt enthält wird die Option Wiederkehrend vorgeschlagen. Wird kein Posten gefunden wird der Wert Erster vorgeschlagen. Anmerkung: Die Option Wiederkehrend wird frühestens nach dem Buchen des ersten SEPA Bankeinzugs vorgeschlagen da in den bisherigen Zahlungsposten die dafür notwendigen Informationen nicht enthalten sind.

Folgende Felder wurden in den Zahlungsposten hinzugefügt: Bankeinzugsmethode SEPA Mandat ID SEPA Mandat erteilt am SEPA Bankeinzugsart

Änderungen

Die Einmalüberweisung wurde in Einmalanweisung umbenannt und steht nun auch für Bankeinzüge zur Verfügung.

Fehlerbehebungen

In der Zahlungsvorschlagsliste wurden Debitorenseitig in gewissen Konstellationen im Role Tailored Client keine Posten angezeigt.

NCP 7.00

Verbesserungen

Der Zahlungsverkehr wurde um die Möglichkeit erweitert Inlandsüberweisung (MT101) und Auslandsüberweisung (MT101) zu erstellen.

Das Zahlungseingangs Buch.-Blatt wurde um die Möglichkeit erweitert Inlandsüberweisung (PAYMUL), Auslandsüberweisung (PAYMUL), Inlandsüberweisung (MT101) und Auslandsüberweisung (MT101) zu erstellen.

Das Zahlungsausgangs Buch.-Blatt wurde um die Möglichkeit erweitert Inlandsüberweisung (MT101) und Auslandsüberweisung (MT101) zu erstellen.

Die Bankkontokarte wurde um das Feld SWIFT-Code MT101 Konvertierungsstelle erweitert.

In der Zahlungsverkehr Einrichtung wurde für die Verwendungszweck-Felder ein neuer Platzhalter %11 hinzugefügt. Dieser kann verwendet werden um den Verwendungszweck mit dem Feld Belegdatum zu füllen.

Im Report Zahlungsvorschlagsliste wird jetzt neben der Nr. des Kreditors/Debitors/Bankkontos/Sachkontos auch der Name angedruckt.

Im Zahlungseingangs Buch.-Blatt und im Zahlungsausgangs Buch.-Blatt wurde ein neues Feld Zahlungstext hinzugefügt. In der Zahlungsverkehr Einrichtung wurde für die Verwendungszweck-Felder ein neuer Platzhalter %12 hinzugefügt. Dieser kann verwendet werden um den Verwendungszweck mit dem Feld Zahlungstext aus den Buch.-Blättern zu füllen. Das Feld Zahlungstext ist standardmäßig ausgeblendet. Das Feld wird nicht vom Zahlungsverkehr befüllt. Es kann also manuell vom Benutzer befüllt werden oder für eine Kundenanpassung frei verwendet werden.

Es können nun auch MT940 Dateien welche Disponierte Umsätze enthalten importiert werden. Disponierte Umsatzblöcke werden dabei übersprungen.

In der Zahlungsverkehr Einrichtung wurde das Register Firmendaten in Auftraggeber umbenannt. Es wurde weiters ein neues Feld Länder/Regionscode hinzugefügt.

In den Tabellen 21 Debitorenposten und 25 Kreditorenposten wurde ein neues Feld Externer Bankkontocode hinzugefügt. Dieses Feld wird im Zahlungsvorschlag berücksichtigt. Funktionsweise: Ist das Feld Externer Bankkontocode in den Kreditoren/Debitorenposten gefüllt wird beim Zahlungsvorschlag das Feld Externer Bankkontocode im Buchblatt mit diesem Wert vorbelegt. Das Feld Externer Bankkontocode 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.

Es ist jetzt erlaubt eine Auslandsüberweisung (PAYMUL) innerhalb Österreichs zu erstellen auch wenn beide Banken (Sender/Empfänger) einen ISO Ländercode = 'AT' hinterlegt haben.

SWIFT-Codes der Länge 8 (Fehlende Kennzeichnung der Filiale oder Abteilung) werden nun, beim Erstellen der Zahlungsdatei, mit XXX auf 11 Stellen ergänzt.

In der Zahlungsverkehr Einrichtung wurde ein neues Feld Externe Bankkontosuche hinzugefügt. Dieses Feld wird im Zahlungsvorschlag berücksichtigt. Funktionsweise: Das Feld hat 2 Optionen: Hauptbankverbindung und Letzte Transaktion. Wird die Option Hauptbankverbindung gewählt wird wie bisher beim Abrufen des Zahlungsvorschlags versucht das Feld Externer Bankkontocode im Buchblatt über die Hauptbankverbindung zu ermitteln. Gibt es keine Hauptbankverbindung beim Kreditor/Debitor wird das Feld befüllt wenn der Kreditor/Debitor nur eine einzige Bankverbindung hinterlegt hat. Ist die Option Letzte Transaktion eingestellt wird versucht anhand der letzten Transaktion einen Wert zu ermitteln. Dabei wird nach der letzten gebuchten Transaktion des Bankkontos mit selber Zahlungsart, Kreditorennr./Debitorennr. und Währungscode gesucht. Für beide Fälle gilt: Sollte der Kreditoren/Debitorenposten im Feld Externer Bankkontocode einen Wert enthalten wird dieser vorgeschlagen.

In der Zahlungsverkehr Einrichtung wurden folgende neue Felder hinzugefügt: SEPA Sammeltransaktion (SCT) SEPA Sammeltransaktion (SDD) Inland Sammeltransaktion (PAYMUL) Inland Sammeltransaktion (DIRDEB) Ausland Sammeltransaktion (PAYMUL) Inland Sammeltransaktion (MT101) Ausland Sammeltransaktion (MT101) Mit diesen Feldern kann man steuern, ob bei der Erstellung der Zahlungsverkehrsdatei Transaktionen zusammengefasst werden sollen und somit als Sammeltransaktionen an die Bank übermittelt werden sollen. Folgende Transaktionen sind davon nicht betroffen: Einzelüberweisungen Überweisungen bei denen eine Zahlungsreferenz angegeben wurde. Ansonsten wird versucht Buchblattzeilen mit selber Kreditorennr./Debitorennr./Bankkontonr., Externer Bankkontocode und Währungscode als eine Transaktion zusammenzufassen und an die Bank zu übermitteln. Dabei ist es bei Überweisungen auch möglich Gutschriften, welche über Ausgleich mit Belegnr. im Buchblatt eingegeben wurden, miteinzubeziehen. Voraussetzung ist dabei, dass die Sammeltransaktion einen positiven Betrag aufweist. Das gilt natürlich umgekehrt auch bei Einzügen. Die Einzeltransaktionen sind im Verwendungszweck bzw. am Bericht Avis ersichtlich. Diese Funktionalität macht vor allem dann Sinn, wenn beim Zahlungsvorschlag die Option Pro Kreditor summieren bzw. Pro Debitor summieren nicht verwendet wird. Wurden Buchblattzeilen zusammengefasst erhält der daraus resultierende Zahlungsposten das Kennzeichen Sammeltransaktion. Weiters wird das Feld Beschreibung im Zahlungsposten mit Sammeltransaktion befüllt. Das Feld Belegnr. und Buchungsdatum des Zahlungspostens wird nur dann befüllt, wenn innerhalb der Sammeltransaktion keine Abweichung besteht. Sollten die Buchblattzeilen aber unterschiedliche Inhalte haben wird das entsprechende Feld leer gelassen.

Die Zahlungsposten wurden um ein neues Feld Avis Anzahl gedruckt erweitert. Dieses Feld zeigt an, wie häufig der Avis zu dem Posten gedruckt wurde. Die Anwendung aktualisiert dieses Feld automatisch bei jedem Ausdruck.

Für Inlandsüberweisung (PAYMUL) und Bankeinzug (DIRDEB) gibt es jetzt die Möglichkeit in der Zahlungsverkehr Einrichtung Überschriften für den Verwendungszweck anzugeben. Ist in dem entsprechenden Überschriftenfeld ein Text angegeben wird dieser im Verwendungszweck als erstes angedruckt. Beispiel: Verwendungszweck Überschrift: 'Info/Betrag (Skonto)' Verwendungszweck: '%1 %2/%6[ (%7)]' Ergebnis: Info/Betrag (Skonto) Zahlung 00112300/12.500 (500) Zahlung A312-5/1000 Zahlung B312-5/990 (10) Zahlung 01004565B/2300

Die Clearingposten sind nun direkt über das Hauptmenü unter dem Punkt Historie aufrufbar.

Die Funktionalität Zahlungsdatei annullieren kann nun auch direkt vom Clearingposten aus aufgerufen werden.

In der Zahlungsverkehr Einrichtung wurde ein neues Feld Eingebettete Clearingdatei speichern hinzugefügt. Ist dieses Feld gesetzt wird zu jedem Clearingposten eine Kopie der Zahlungsdatei in der Datenbank gespeichert.

In der Zahlungsverkehr Einrichtung wurden für die Dateinamen folgende neue Platzhalter hinzugefügt: %7 Dateireferenz, %8 Clearingposten Lfd. Nr., %9 Benutzer ID

Die Felder BLZ und SWIFT-Code können nun mittels LookUp von einer Tabelle Bankcodes ausgewählt werden. Die Funktionalität entspricht hier jener der PLZ-Code/Ort Felder im Standard. D.h. weder die BLZ noch der SWIFT-Code müssen zwingend in der Bankcode Tabelle angelegt sein. Für Bankcodes stehen Import/Export und Downloadfunktionen zur Verfügung. Derzeit stehen Bankcodes für Österreich und Deutschland zum Download bereit.

Für MT940 Buchungscodes und MT940 Geschäftsvorfallcodes stehen jetzt anstatt der Erstellen Buttons Import/Export und Downloadfunktionen zur Verfügung.

In der Zahlungsverkehr Einrichtung wurden folgende neue Felder hinzugefügt: SEPA Avis immer erstellen (SCT) SEPA Avis immer erstellen (SDD) Inland Avis immer erstellen (PAYMUL) Inland Avis immer erstellen (DIRDEB) Ausland Avis immer erstellen (PAYMUL) Inland Avis immer erstellen (MT101) Ausland Avis immer erstellen (MT101) Mit diesen Feldern kann man steuern ob bei der Erstellung der Zahlungsverkehrsdatei, unabhängig davon ob der Verwendungszweck vollständig übermittelt werden kann oder nicht, immer ein Avis erstellt werden soll.

Änderungen

Die Versionsliste der Objekte wurde von NCZV auf NCP geändert.

Die Erweiterungen im Feld Bankkontozahlungsart aus der Buch.-Blattzeile wurden entfernt und befinden sich nun in dem neuen Feld Zahlungsart.

Bei der Eingabe von Absender Identifikation und Empfänger Identifikation auf der Bankkontokarte werden jetzt alle eingegebenen Leerzeichen entfernt.

Das Feld Zahlungsreferenz wurde aus der Tabelle 21 Debitorenposten entfernt. In der Zahlungsverkehr Einrichtung wurde stattdessen das Feld Zahlungsreferenz Feldnr. hinzugefügt. Hier kann angegeben werden, welches Feld der Tabelle Debitorenposten die Zahlungsreferenz enthält. Da es hier keine allgemein gültige Vorgehensweise gibt, zu welchem Zeitpunkt die Referenz ermittelt wird und wie diese Referenz danach dem Debitor für die Zahlung zur Verfügung gestellt wird, ist dieses Feld und die Vergabe der Referenz bei Bedarf über eine Individualprogrammierung umzusetzen. Die Funktionen in der Bankkontoabstimmung für den Ausgleichsvorschlag (nach dem Einlesen einer MT940 Datei) berücksichtigt jetzt das neue Feld Zahlungsreferenz Feldnr. aus der Zahlungsverkehr Einrichtung.

Die Felder SEPA Aufteilungsbetrag und SEPA Aufteilungsbetragsgrenze auf der Bankkontokarte wurden entfernt.

Die Prüfungen für BLZ, Kontonummer, SWIFT Code, IBAN und Routing wurden geändert.

Das Feld Bankbuchungsschema der Zahlungsverkehr Einrichtung wurde geändert. Das Feld hatte 2 Optionen Zeilenweise und Kontoweise. Zeilenweise hatte keine Auswirkungen. Bei Kontoweise wurde beim Erstellen der Zahlungsverkehrsdatei eine Gegenbuchungszeile für Buchungen mit identischem Konto, Buchungsdatum, Belegnr. und Währungscode im Buchungsblatt angelegt. Das Feld wurde durch das neue Feld Gegenkonto Sammelbuchungszeile erstellen ersetzt.

Die Generierung der Auftragsreferenz und Auftraggeberreferenz wurde bei der Erstellung der Zahlungsverkehrsdatei geändert. Basis für die Referenzfelder ist wie bisher auch die Dateireferenz.

Das Feld Zahlung Bankkontocode wurde im Zahlungsverkehr in Externer Bankkontocode umbenannt.

Die erlaubten Zeichen in einer SEPA Datei wurden geändert. Folgende Zeichen sind erlaubt: abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 /-?:().,'+ Leerzeichen Für Österreichische Bankkonten sind zusätzlich folgende Zeichen erlaubt: &; Umlaute werden wie bisher automatisch konvertiert. Aus 'Ä' wird 'Ae', 'Ö' wird zu 'Oe' usw. Für Österreichische Bankkonten werden zusätzlich folgende Zeichen automatisch konvertiert: < wird zu '&lt;' > wird zu '&gt;' & wird zu '&amp;' " wird zu '&quot;' ' wird zu '&apos;' Bei allen andern Bankkonten wird folgendes Zeichen automatisch konvertiert: & wird zu + Zeichen die nach der Konvertierung übrig sind und nicht in der Datei erlaubt sind werden durch ein Leerzeichen ersetzt.

Das Verhalten des Kreditor/Debitor Zahlungsvorschlags wurde angepasst. Funktionsweis Zahlungsvorschlag: Wird keine Zahlungsart ausgewählt bringt der Vorschlag Kreditorenseitig nur Kreditoren an denen ein Betrag zu zahlen wäre. Debitorenseitig würden nur Debitoren vorgeschlagen von denen ein Betrag fällig wäre. Für beide Seiten gilt: Wird die Zahlungsart Inlandsüberweisung (PAYMUL), Auslandsüberweisung (PAYMUL), SEPA Überweisung (SCT), Inlandsüberweisung (MT101) oder Auslandsüberweisung (MT101) gewählt werden nur Kreditoren/Debitoren vorgeschlagen, an denen ein Betrag zu zahlen wäre. Wird Bankeinzug (DIRDEB) oder SEPA Bankeinzug (SDD) ausgewählt bringt der Vorschlag nur Debitoren von denen ein Betrag fällig wäre. Zusätzlich wird bei der Auswahl von Inlandsüberweisung (PAYMUL), Bankeinzug (DIRDEB), SEPA Überweisung (SCT) oder SEPA Bankeinzug (SDD) noch auf EURO Beträge gefiltert.

Die Prüfungen auf das Ändern eines Ausgleichs (Ausgleichs-ID, Ausgleich mit Belegart/Belegnr.) nachdem bereits eine Zahlungsdatei erstellt wurde wurden verbessert.

Das Feld Zahlung erstellt aus der Buch.-Blattzeile wurde durch das neue Feld Zahlungsstatus ersetzt.

In der Zahlungsverkehr Einrichtung wurde das Feld SEPA Verwendungszwecklänge entfernt. Die Länge wird nun automatisch durch das jeweilige SEPA Schema bestimmt.

Fehlerbehebungen

Pro Kreditor/Debitor ist es nur mehr möglich eine Bank als Hauptbankverbindung zu setzen.

NCP 6.19

Verbesserungen

Die SEPA Schemata wurden erweitert. Es stehen jetzt auch Schweizer Schemata zur Verfügung.

Im Register MT940 der Zahlungsverkehr Einrichtung wurde ein neues Feld MT940 Datei speichern hinzugefügt. Ist dieses Feld gesetzt wird die MT940 Datei beim Import in der MT940 Import Tabelle gespeichert. Im Fenster MT940 Import wurde ein neues Feld Eingebettete Datei vorhanden hinzugefügt. Dieses Feld ist standardmäßig nicht sichtbar. Wenn das Feld eingeblendet wird kann über einen Klick auf das Feld die Datei gelöscht oder exportiert werden.

Änderungen

Das Design des Fensters MT940 Import wurde angepasst.

Fehlerbehebungen

Es können nun auch MT940 Dateien welche Header/Block Informationen enthalten importiert werden.

NCP 6.18

Änderungen

Der Teil Name des Kreditinstitutes und Ortsangabe der Zweigstelle (beides 70 Stellen) in Segmentgruppe 12 FII C088 wurde bisher bei Auslandsüberweisungen mit den Informationen des Kontoinhabers befüllt. Das wurde geändert. Name des Kreditinstitutes wird jetzt mit den Feldern Name und Name 2 der jeweiligen Bankkontokarte des Kontoinhabers befüllt. Ortsangabe der Zweigstelle wird mit der Adresse, Adresse 2, PLZ, Ort und Land/Region der jeweiligen Bankkontokarte des Kontoinhabers befüllt.

Die Kontoinhaber Felder wurden bisher mit Name und Ort des Kontoinhabers befüllt. Hier wurde eine Erweiterung um den Namen 2 vorgenommen.

NCP 6.16

Fehlerbehebungen

Gab es zu einem Datensatz keinen Verwendungszweck wurde ein leerer FTX Block (Segmentgruppe 16) in die Zahlungsdatei geschrieben.

Bei Auslandsüberweisung (PAYMUL) konnte in gewissen Konstellationen die Gesamtauftragssumme (Segmentgruppe 5) von der Summe der Einzelaufträge abweichen. Dabei war lediglich die Anzeige im Bankprogramm betroffen, nicht die tatsächlich zu überweisenden Beträge.

Die Auftraggeberreferenz war in gewissen Konstellationen nicht eindeutig.

NCP 6.15

Änderungen

Bisher wurde im Zahlungsverkehr bei SEPA Datenträgern in der <EndToEndId> die Auftraggeberreferenz geschrieben wenn keine Zahlungsreferenz angegeben wurde. Aufgrund einer Umstellung ist das nicht mehr möglich. Die <EndToEndId> darf nur mehr die Zahlungsreferenz oder den Wert NOTPROVIDED enthalten.

NCP 6.14

Verbesserungen

Der MT940 Import kann nun auch unstrukturierten Verwendungszweck einlesen.

Die Funktion Erstellen im Fenster MT940 Geschäftsvorfallcodes wurde um weitere Codes ergänzt. Es werden AT und DE Codes vorgeschlagen.

NCP 6.13

Fehlerbehebungen

Im Release NCP 6.12 der NAV Versionen 3.60 und 3.70 konnte man die Bankkontozahlungsart im Report Zahlungsvorschlag (ID 393) nicht wählen bzw. wurde eine Auswahl im Feld vom Report nicht berücksichtigt. Version NCP 6.13 ist nur für Version NAV 3.60 und NAV 3.70 verfügbar.

NCP 6.12

Verbesserungen

Das Feld Änderung nach "Zahlung erstellt" zugelassen aus der Zahlungsverkehr Einrichtung wirkt sich jetzt auch auf den Ausgleich im Buch.-Blatt aus. Ist das Feld nicht gesetzt darf der Ausgleich in einem Buch.-Blatt nicht mehr geändert werden wenn das Feld Zahlung erstellt gesetzt ist.

Zu jedem Bankposten, Clearingposten, Zahlungsposten und Verwendungsposten kann man jetzt Bemerkungen hinterlegen.

Die Prüfungen im Zahlungsvorschlag auf bereits gesetzte Ausgleichs IDs wurde verbessert.

Das Routing (Verwendung in EDIFACT Dateien) findet jetzt mehr Länder.

EDIFACT Dateien können nun auch erstellt werden wenn nur der IBAN bekannt ist. D.h. BLZ und Kontonummer sind in dem Fall keine Pflichtfelder mehr.

In der Zahlungsverkehr Einrichtung wurde für die Datei-Felder ein neuer Platzhalter %6 hinzugefügt. Dieser kann verwendet werden um den Dateinamen mit der Bankkontonr. zu erweitern.

In der Zahlungsverkehr Einrichtung wurde für die Verwendungszweck-Felder ein neuer Platzhalter %10 hinzugefügt. Dieser kann verwendet werden um den Verwendungszweck mit dem Feld Beschreibung aus dem Buch.-Blatt zu füllen.

Im Verwendungszweck der Zahlungsverkehr Einrichtung kann nun die maximale Zeichenanzahl eines Platzhalters begrenzt werden. Dies wird durch die Angabe eines Zahlenwertes innerhalb spitzer Klammern direkt nach dem Platzhalter erreicht.

Der MT940 Import kann nun auch MT940 Dateien mit IBAN und BIC importieren. Hierfür wurde die MT940 Bankkontozuordnung verändert. Die Kontobezeichnung (Identifikation des Bankkontos) wird nicht mehr aufgesplittet. Dadurch können auch Dateien mit weniger starrem Bankkontozuordnungsformat eingelesen und zugeordnet werden.

Die Datei-Erstellung im Bereich SEPA wurde geändert. Der Aufbau der XML-Dateien wird ist jetzt nicht mehr starr im Code hinterlegt sondern muss eingerichtet werden. Im Zahlungsverkehr gibt es unter Einrichtung einen neuen Menüpunkt SEPA Schemata. Hier werden die Schemata der unterschiedlichen SEPA Formate eingerichtet. Diese können Importiert werden oder über den Menüpunkt Download direkt in die Tabelle geladen werden. Nach dem Download (oder Import) der benötigten Schemen müssen diese den Bankkonten zugeordnet werden. Derzeit werden 2 Schemata unterstützt: Überweisung (SCT) und Bankeinzug (SDD). Zum Release-Zeitpunkt stehen die Schemata für die Österreich und Deutschland zum Download bereit. Je nachdem welches Schema dem Bankkonto zugeordnet wurde unterscheiden sich die XML-Dateien in ihrem Aufbau (z.B. DE-Format oder AT-Format). Der ISO Ländercode des Bankkontos muss beim Erstellen der Datei mit dem ISO Ländercode des Schemas übereinstimmen.

Änderungen

Wird im SEPA kein Verwendungszweck gefunden wird n/a in die Datei geschrieben.

NCP 6.11

Verbesserungen

Im Zahlungsausgangs und Zahlungseingangs Buch.-Blatt wurde im Role Tailored Client die Zahlungsvorschlagsliste in die Menüleiste aufgenommen.

Der Zahlungsvorschlag prüft nun bei Kreditorenposten und Debitorenposten gesetzte Ausgleichs IDs und gibt diese frei wenn sie im System nicht mehr verwendet werden.

Änderungen

In der Caption der Zahlungsposten wurde im Role Tailored Client Überweisungsposten angezeigt.

Die Funktion Zahlungsdatei erstellen ignoriert nun die Leerzeichen in den Feldern Absender Identifikation und Empfänger Identifikation des Bankkontos.

File-Handling für den Role Tailored Client wurde im Bereich Zahlungsdatei erstellen überarbeitet.

Fehlerbehebungen

Die Verwendungsposten (Zahlungsdetails) wurden in gewissen Konstellationen nicht richtig berechnet. Dies wirkte sich auf das Ergebnis der Zahlungsvorschlagsliste, Avis und der Verwendungszwecke in der Zahlungsdatei aus.

Docs  /  NCP Zahlungsverkehr (NAV)  /  Anhang
Upgrade auf Business Central

Voraussetzungen für das Upgrade

• Mindestens NCP 13.00 Ältere Versionen von NCP müssen zuerst in NAV aktualisiert werden.

Dateien für das Upgrade

Vorbereitung 1: Alte Tabellen in der NAV-Datenbank umbenennen

Vorbereitung 2: Alte Felder in den Standard-Tabellen der NAV-Datenbank umbenennen

APPLICATION UPGRADE

[Microsoft Docs] Business Central - Upgrading Customized C/AL Application to Microsoft Base Application Version 19

Task 3: Move code customizations to extensions

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-to-microsoft-base-app-v19#task-3-move-code-customizations-to-extensions

Task 4: Create empty System, Base, and customization extensions

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-to-microsoft-base-app-v19#task-4-create-empty-system-base-and-customization-extensions

Task 5: Create table migration extension

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-to-microsoft-base-app-v19#task-5-create-table-migration-extension

migration.json
{
    "apprules": [
        {
            "id": "63ca2fa4-4f03-4f2b-a480-172fef340d3f"
        },
        {
            "id": "437dbf0e-84ff-417a-965d-ed2bb9650972"
        },
        {
            "id": "2c40ba68-7b3b-4783-ba82-b1094db31332"
        }
    ]
}

Task 10: Publish DestinationAppsForMigrations extensions

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-to-microsoft-base-app-v19#task-10-publish-destinationappsformigrations-extensions

Task 12: Install DestinationAppsForMigration and move tables

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-to-microsoft-base-app-v19#task-12-install-destinationappsformigration-and-move-tables

Task 13: Publish final extensions

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-to-microsoft-base-app-v19#task-13-publish-final-extensions

Task 14: Synchronize final extensions

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-to-microsoft-base-app-v19#task-14-synchronize-final-extensions

Task 17: Upgrade and install final extensions

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-to-microsoft-base-app-v19#task-17-upgrade-and-install-final-extensions

Nach dem Upgrade

1. NAVAX Consulting GmbH_NCP Payments Base by NAVAX_14.0.0.0.app
2. NAVAX Consulting GmbH_NCPE Payments Export by NAVAX_14.0.0.0.app
3. NAVAX Consulting GmbH_NCPI Payments Import by NAVAX_14.0.0.0.app