Zahlungsverkehr / SEPA-Export

Hallo,

hat jemand eine Hilfestellung für folgende Meldung?

gegenkontonr.PNG

Die Gegenkontonr. ist durchaus eingetragen, trotzdem kann ich nicht exportieren ...

In der Bankkarte ist unter Transfer als Format für den Zahlungsexport SEPACT ausgewählt worden.

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Du hast das Gegenkonto auch im FiBu Buch.-Blattnamen hinterlegt?

Hallo Danis,

nein, habe ich (noch) nicht ... Ich will wohl, in der Auswahlliste steht das Konto auch drin, ich kann es aber nicht auswählen bzw. übernehmen.

Edit: ah, man kann die Liste auch bearbeiten ... Also das Konto ist jetzt drin.

Nun kann ich auch exportieren. Aber, das ist nur eine "normale" XML-Datei, keine im SEPA-Format (pain ...). Wie bekomme ich diese?

So, weiter geforscht ... Die Datei im richtigen Format kann nun erzeugt und auch bei der Bank eingelesen werden. Problem ist aktuell noch, dass der Zahlungszweck nicht exportiert wird, hier steht nur der Firmenname des Empfängers anstatt der Rechnungsdaten und (Einzel-)Beträge. Wie kommt man da ran?

Edit: Lösung habe ich noch nicht, aber im Buchblatt für den Zahlungsausgang steht im Feld Beschreibung der Firmenname des Empfängers. Hier müsste eigentlich der Verwendungszweck stehen. Wo muss man denn dafür eingreifen?

Weitere Erkenntnisse: wenn der Zahlungsvorschlag im Buchblatt Zahlungsausgang genutzt wird, dann wird jede passende Rechnung in einer einzelnen Zeile aufgeführt und auch das Feld "Nachricht an Empfänger" mit "Zahlung von Rechnung x" gefüllt. Soweit so gut ...

Meine Annahme war hingegen, wenn ich manuell eine Zeile hinzufüge und über "Posten ausgleichen" einen oder mehrere Posten markiere, dass dann auch das Feld "Nachricht an Empfänger" gefüllt wird. Dem ist leider nicht so und etwas unlogisch / praxisfremd.

Beim Zahlungsvorschlag ist aber auch so, dass zwar der Vorschlag dort steht, aber kein Posten damit ausgeglichen wird, weil die Ausgleichs-ID nicht gesetzt ist ... wer denkt sich denn so etwas aus bzw. welchen Sinn macht das?

Aktuelles Fazit nach ein paar Tagen Beschäftigung mit dem Zahlungssystem ist: das ZS ist im NAV-Standard weder funktionsfähig (im Sinne von Zahlungen erstellen und im SEPA-Standard exportieren) und zumindest etwas praxisfremd. Mir ist klar, dass es Erweiterungen wie OPPlus gibt und das ist bestimmt alles ganz toll, nur wäre es schon für einen Endkunden ein Rückgabegrund, wenn eine absolute Standardfunktionalität nicht ohne Anpassungen nutzbar ist.

Ich habe diverse Hinweise gelesen, dass MS nichts in Richtung SEPA machen würde, weil angeblich keine Standards und von Bank zu Bank verschieden. Das mag sein, aber unsere Erfahrung ist auch, dass wir bei Endkunden mit dem SEPA-Export einer anderen Software bei keiner Bank oder Bankprogrammen wie ProfiCash, WinData, DBDirekt etc. irgendein Problem hatten. Also kann der SEPA-Export nicht sooo problematisch sein wie von MS dargestellt (Beiträge mit Problemen / Notwendigkeit von Anpassungen bei Zweigstellen in verschiedenen Ländern habe ich gelesen, mir geht es hier lediglich um den Zahlungsverkehr in D).

Beim Zahlungsvorschlag ist aber auch so, dass zwar der Vorschlag dort steht, aber kein Posten damit ausgeglichen wird, weil die Ausgleichs-ID nicht gesetzt ist ... wer denkt sich denn so etwas aus bzw. welchen Sinn macht das?

Es gibt nicht nur die "Ausgleichs-ID" in den Buchblättern, sonder auch die Spalten "Ausgleich mit Belegart" und "Ausgleich mit Belegnr.". Diese Felder machen bei einem 1:1 Ausgleich mehr Sinn, da sie direkt auf den einen Beleg verweisen, der auch im Buchblatt steht.

Gruß Fiddi

Hallo Fiddi,

habe ich nun auch gemerkt und gleich umgesetzt:

zv_1.PNG

Allerdings kann ich die Zahlungen nicht exportieren, weil:

zv-2.PNG

Inwiefern wird nun Sachkonto 1360 mit "Bankkonto ist nicht vorhanden" angemeckert?

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Der letzte Punkt ist noch offen: wie bekomme ich bei Verbuchung von Zahlungsausgängen die Verbuchung auf Kto. 1360 / Geldtransit / SKR03 hin?

Das Gegenkonto für den Zahlungslauf sollte ein Bankkonto sein, kein Sachkonto!

Aus Buchhaltungssicht ist das falsch ...: Zahlungslauf bedeutet lediglich, dass eine Zahlung veranlasst wurde. Wenn ich im Zahlungslauf das Bankkonto anspreche, verändert sich schon der Saldo dieses Kontos. Der darf sich aber erst verändern, wenn ich den Kontoauszug buche (weil keine Buchung ohne Beleg).

Normal ist Buchung im Zahlungslauf Debitor an 1360 (im SKR03) und dann beim Buchen des Kontoauszuges 1360 an Bank.

Ich habe mehrere Bankkonten, eines das ich als Zwischenkonto verwende. Natürlich buche ich den Zahlungslauf nicht direkt auf das eigentliche Bankkonto. Die Akquinet Lösung kennt Transitkonten. Vom Microsoft Zahlungsverkehr (den es ja erst seit NAV 2013 R2 gibt) hab ich diesbezüglich keine Ahnung.

Natürlich buche ich den Zahlungslauf nicht direkt auf das eigentliche Bankkonto. [...] Vom Microsoft Zahlungsverkehr (den es ja erst seit NAV 2013 R2 gibt) hab ich diesbezüglich keine Ahnung.

Was mir bei den hiesigen Diskussionen schon öfters aufgefallen ist: elementare Dinge, bspw. den Zahlungsverkehr, kann man mit NAV scheinbar (!) nur vernünftig mit Fremd-Ergänzungen durchführen, anders lassen sich die Hinweise nicht interpretieren. Wobei das von Dir genannte NAV 2013 ja auch schon ein paar Jahre (!) alt und NAV 2016 eben aktuell ist.

Was nun das Zwischenkonto angeht, ist doch im SKR03 eben 1360 als Zwischenkonto für den Zweck definiert. Dann ist es doch eigentlich ein Unding ein "richtiges" Bankkonto dafür zu verwenden. Vermutlich lässt sich das auch alles wie gewünscht einstellen, aber NAV ist eben auch bei grundlegenden Erfordernissen wohl nicht out of the Box benutzbar. Bei ähnlich großen Lösungen ist das aber durchaus für die üblichen Standardvorgänge der Fall. Das jede Firma spezielle Anforderungen hat, brauchen wir nicht zu diskutieren, ich mache fast 30 Jahre Softwareentwicklung primär im kaufm. Bereich und kenne diverse Anforderungen. Nur das bei solchen täglichen Standardvorgängen rumgehampelt werden muss ist mir neu ...

Ich lerne aber gern dazu. Eine Anfrage zur Unterstützung habe ich im passenden Bereich gestellt. Vielleicht hat jemand Lust?

Was mir bei den hiesigen Diskussionen schon öfters aufgefallen ist: elementare Dinge, bspw. den Zahlungsverkehr, kann man mit NAV scheinbar (!) nur vernünftig mit Fremd-Ergänzungen durchführen, anders lassen sich die Hinweise nicht interpretieren. Wobei das von Dir genannte NAV 2013 ja auch schon ein paar Jahre (!) alt und NAV 2016 eben aktuell ist.

Kurz hierzu: Das war das Konzept von NAVISION dass der Hersteller nur eine Art Betriebssystem liefert das von Partnern dann zur vollständigen Lösung ausgebaut wird. Seit Microsoft NAV übernommen hat ändert sich das nach und nach, aber selbst heute empfehlen die NAV'ler von Microsoft Deutschland z. B. nicht den Zahlungsverkehr von MS zu nutzen. Bestandskunden, und das sind nunmal die meisten, nutzen historisch bedingt ohnehin den Akquinet Zahlungsverkehr.

Außerdem wurden Partnerlösungen teilweise über die Preisliste von Microsoft verkauft, so auch der Akquinet Zahlungsverkehr, so dass Endkunden gar nicht bewusst war (oder ist) dass Sie Partnerlösungen einsetzen.

Was nun das Zwischenkonto angeht, ist doch im SKR03 eben 1360 als Zwischenkonto für den Zweck definiert. Dann ist es doch eigentlich ein Unding ein "richtiges" Bankkonto dafür zu verwenden. Vermutlich lässt sich das auch alles wie gewünscht einstellen, aber NAV ist eben auch bei grundlegenden Erfordernissen wohl nicht out of the Box benutzbar.

Du kannst doch das Konto 1360 als Bankonto anlegen. Das einzige Problem ist doch dass es ein Bankkonto statt einem Sachkonto sein muss. So schwierig ist es nicht als Art=Bankkonto statt Art=Sachkonto zu verwenden. Bankonto mit Nr. und Buchungsgruppe 1360 anlegen, fertig.

Ein verbreitetes Missverständnis zu NAV ist dass man mit speziell deutschen Buchhaltungs- oder noch schlimmer Steuerrechts-Erfordernissen (oder nur Üblichkeiten) an NAV rangeht. NAV ist aber nicht aus dieser deutschen Sicht programmiert, das kann DATEV sicher besser. NAV versucht auch speziell deutsche Probleme zu lösen (z. B. GDPdU), dann aber mit einer Lösung die weltweit passen soll. Sowas ist nicht immer optimal, aber so ist NAV eben.

@enh, danke für die Erläuterungen.

Dann ist es doch eigentlich ein Unding ein "richtiges" Bankkonto dafür zu verwenden.

Wie schon beschrieben, das ist nur ein Hilfsunterkonto und kein richtiges.
In SAP läuft das übrigens genauso .

mir geht es hier lediglich um den Zahlungsverkehr in D

Das mag in deinem Fall zutreffen, aber wenn MS dort wirklich aktiv werden würde, müsste es schon nicht nur eine nationale und auch keine europäische, sondern eine globale Lösung sein. Verglichen mit dem "großen Bruder" ISO 22022, für den SEPA als dessen Subset quasi der Testballon war, ist der Konfigurationsaufwand bei SEPA nur "Kindergeburtstag", bei ISO 20022 wird es noch erheblich komplexer und ist dann auch "nur" die moderne Option für internationale Transaktionen, die noch nicht von allen Banken unterstützt wird.