NCP 8.10 für Microsoft Dynamics NAV 2016*

Transkript

1 Changes NC Payments NCP 8.10 für Microsoft Dynamics NAV 2016* *NC Payments 8.10 ist verfügbar für Navision Attain 3.60, Microsoft Business Solutions Navision 3.70, Microsoft Business Solutions Navision 4.0 SP3, Microsoft Dynamics NAV 5.0 SP1, Microsoft Dynamics NAV 2009 R2, Microsoft Dynamics NAV 2013, Microsoft Dynamics NAV 2013 R2, Microsoft Dynamics NAV 2015 und Microsoft Dynamics NAV 2016.

2 Disclaimer Dieses Dokument dient nur zu Informationszwecken. Bei Verwendung zu anderen Zwecken lehnt die NAVAX Consulting GmbH jede Gewährleistung wegen Sach- und Rechtsmängeln ab. Die NAVAX Consulting GmbH lehnt jede Haftung für direkte und indirekte Schäden - sei es aus Vertrag oder aus Gesetz - ab, die in Verbindung mit der Anwendung und sonstiger Nutzung des Dokuments entstehen können. Dieses Dokument kann bei Bedarf ohne vorherige Ankündigungen von der NAVAX Consulting GmbH geändert werden. Die NAVAX Consulting GmbH lehnt jede Haftung für Fehler und Unterlassungen in diesem Dokument ab. Der Inhalt dieses Dokuments ist urheberrechtlich geschützt. Ohne schriftliche Erlaubnis der NAVAX Consulting GmbH darf kein Teil dieses Dokuments für irgendwelche Zwecke, vervielfältigt oder übertragen werden, unabhängig davon, auf welche Art und Weise oder mit welchen Mitteln, elektronisch oder mechanisch, dies geschieht. Es gelten die Allgemeinen Geschäftsbedingungen der NAVAX Consulting GmbH, diese entnehmen Sie bitte unserer Homepage NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 2 von 44

3 Inhaltsverzeichnis NCP Update... 5 NCP NCP NCP NCP NCP NCP NCP NCP NCZV NCZV NCZV NCZV NCZV NCZV NCZV NCZV NCZV NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 3 von 44

4 Dieses Dokument enthält Informationen über Änderungen zwischen den Versionen. Bei Fragen wenden Sie sich an: NAVAX EURO PLAZA Technologiestraße 8 A-1120 Wien Tel.: applications@navax.com NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 4 von 44

5 NCP Update Verfügbare Update Codeunits: NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 5 von 44

6 NCP 8.10 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: 1.) 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. 2.) 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. NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 6 von 44

7 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 "XML 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. Das Feld Creditor ID in der Zahlungsverkehr Einrichtung wurde umbenannt zu Creditor Identifier (CI). 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. NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 7 von 44

8 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. Zahlungsverkehr Import Fixe Kontozuordnungen können jetzt nicht mehr Importiert/Exportiert werden. Fehlerbehebung: 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. Fehlerbehebung: Im Zahlungsvorschlag wurde bei Überweisungen ein Fehler in Verbindung mit der Option Verfügbarer Betrag (MW) korrigiert. Es wurden Anpassungen für eine einfachere Lizensierung von NC Payments durchgeführt. 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. NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 8 von 44

9 NCP 8.00 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. 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. NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 9 von 44

10 Im Verwendungszweck der Zahlungsdatei werden jetzt die Tausendertrennzeichen der Betragsfelder (Betrifft Parameter %6 und %7) automatisch entfernt. 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 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 Funktionalität zu testen. Wird die Funktion aufgerufen, muss im Feld Testnachricht an die 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. In der Zahlungsvorschlagsliste wurden in der Zusammenfassung die Vorzeichen der Beträge geändert. NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 10 von 44

11 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. 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. NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 11 von 44

12 NCP 7.12 Fehlerbehebung: In der Bankkontoabstimmung und am Bankkontoauszug wurden im Feld Verwendungszweck keine Werte angezeigt. In der Bankkontoabstimmung und am Bankkontoauszug wird jetzt auch der unstrukturierte Verwendungszweck angezeigt. NCP 7.11 Fehlerbehebung: 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: 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. Fehlerbehebung: Der Filter im Aufruf der Zahlungsposten über die Kreditorenkarte und über die Kreditorenübersicht war fehlerhaft. Fehlerbehebung: Der Avis Vorschlag brachte in gewissen Konstellationen nach dem Senden der eine Fehlermeldung. Betroffen davon waren Versionen ab NAV NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 12 von 44

13 Fehlerbehebung: Wurde ein Avis per gesendet, wurde das Feld Avis gedruckt im Zahlungsposten gesetzt. Betroffen davon waren Versionen ab NAV NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 13 von 44

14 NCP 7.10 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: 1.) Datensätze anlegen wenn nicht vorhanden 2.) Datensätze anlegen & vorhandene Datensätze überschreiben Option 1 legt nur neue Zahlungsverkehr Codes an. Option 2 überschreibt bzw. aktualisiert die vorhandenen Codes (z.b. Feld Beschreibung) 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: 1.) Datensätze anlegen wenn nicht vorhanden 2.) Datensätze anlegen & vorhandene Datensätze überschreiben Option 1 legt nur neue Bankcodes an. Option 2 ü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. Der Aufruf der Clearingposten über ein Bankkonto zeigt keine annullierten Posten mehr. Der Filter kann durch den Benutzer aufgehoben werden. NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 14 von 44

15 Der Aufruf der Zahlungsposten über ein Bankkonto bzw. Debitor/Kreditor Bankkonto zeigt keine annullierten Posten mehr. Der Filter kann durch den Benutzer aufgehoben werden. Die Zahlungsposten können jetzt auch direkt vom Debitor/Kreditor aus aufgerufen werden. Das Feld Buchungscode im MT940 Import wurde in SWIFT Transaktionscode umbenannt. Über AssistEdit im MT940 Import, Feld Importierte Datei ist es nun möglich den Ordner von welchem die MT940 Datei importiert wurde zu öffnen. 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. Fehlerbehebung: 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. NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 15 von 44

16 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. 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. 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: NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 16 von 44

17 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. 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: NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 17 von 44

18 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. 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: NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 18 von 44

19 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: 1.) Wenn der Ländercode des eigenen und des externen Bankkontos SEPA gesetzt haben. 2.) Der ISO Währungscode der Transaktion EUR ist. Bei Zahlungsart Non-SEPA: 1.) wenn Zahlungsart SEPA nicht möglich ist. Bei EDIFACT Inland (PAYMUL/DIRDEB): 1.) Wenn das eigene und das externe Bankkonto im ISO Ländercode als 'AT' definiert sind. 2.) Der ISO Währungscode der Transaktion EUR ist. Bei EDIFACT Ausland (PAYMUL): NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 19 von 44

20 1.) wenn Zahlungsart EDIFACT Inland nicht möglich ist. 2.) Das eigene Bankkonto im ISO Ländercode als 'AT' definiert ist. 3.) 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: 1.) Wenn der ISO Ländercode des eigenen Bankkontos ident mit dem ISO Ländercode des externen Bankkontos ist. Bei MT101 Ausland: 1.) 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: 1.) Es wird nicht nach Währungscode gefiltert. 2.) 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. NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 20 von 44

21 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. NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 21 von 44

22 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. 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. 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. NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 22 von 44

23 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 Druchführungsdatum der Ersten Transaktion gesetz. 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. XML bzw. SEPA und Non-SEPA Zahlungsdateien unterstützen jetzt mehrere Auftragsbestände (B-Level) innerhalb einer Datei. 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, das, 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. 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. Nachfolgend ein Beispiel mit Dateireferenz = NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 23 von 44

24 EDIFACT (Keine Änderung): Auftragsreferenz (Bestandskontrollnr.) Transaktionsreferenz (Auftraggeberreferenz) Alt Neu Alt Neu SEPA und MT101: Auftragsreferenz (Bestandskontrollnr.) Transaktionsreferenz (Auftraggeberreferenz) Alt Neu Alt Neu Die erlaubten Zeichenausnahmen für Österreichische Bankkonten wurden geändert. Grundsätzlich sind folgende Zeichen erlaubt: abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ /-?:().,'+ Leerzeichen Bisher war es so, dass bei Österreichischen Bankkonten zusätzlich folgende Zeichen erlaubt waren: &; Zusätzlich wurden folgende Zeichen automatisch konvertiert: < wurde zu '<' > wurde zu '>' & wurde zu '&' " wurde zu '"' ' wurde zu '&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. NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 24 von 44

25 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: 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. Ü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. NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 25 von 44

26 Beim Annullieren eines bereits gebuchten Clearingpostens kommt nun eine weitere Rückfrage. Der Avis kann jetzt auch per verschickt werden. Der Avis 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 verschicken. Über den Menüpunkt Avis Vorschlag wird zuerst ein Vorschlag erstellt. Dieser Vorschlag wird nicht gespeichert sondern bei jedem Aufruf von Avis Vorschlag neu generiert. Die Adresse an den der Avis geschickt werden soll, wird über das neue Feld Avis (Register Kommunikation) beim Debitor bzw. Kreditor hinterlegt. Standardmäßig werden nur für diejenigen Debitoren/Kreditoren ein Vorschlag erstellt, die in diesem Feld eine Adresse hinterlegt haben. Ist die Option Inklusive Konten ohne Avis beim Vorschlag gesetzt werden auch Debitoren/Kreditoren ohne Avis 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 s 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: 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 kann nur dann gesendet werden, wenn ein Avis Text mit einem Betreff existiert. Hat der Avis Text zusätzlich einen 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. NAVAX Deutschland Österreich Schweiz NC Payments CHANGES Seite 26 von 44