Hallo Community,
wir exportieren seit Dekaden Ausgangsrechnungen aus unserem Warenwirtschaftssystem an eine Buchhaltungssoftware eines Drittanbieters. Bedingt durch eine Umstellung wollen wir nun an DATEV Kanzlei-Rechnungswesen exportieren.
Uns liegt die Dokumentation
"ASCII-Import/-Export: Standardformate und individuelle Formate"
vor. Unter der
"4.2 Feldbeschreibung Buchungsstapel"
sehen wir keine Möglichkeit die Fälligkeiten als Datum zu übergeben. Unser Warenwirtschaftssystem erstellt die Rechnungen und rechnet demzufolge
Datum Skonto 1
Skontobetrag 1
Datum Skonto 2
Skontobetrag 2
Nettofälligkeit
ordnungsgemäß aus. In diesem System können wir dreistellig alphanumerisch Zahlungsbedingungen anlegen, ferner können wir auch je Kunde eine individuelle Zahlungsbedingung hinterlegen. DATEV kennt gem. Erklärung unseres StB lediglich zweistellige numerische Zahlungsbedingungsschlüssel.
Wir müssten nun in unserem Warenwirtschaftssystem jedem Zahlungsbedingungsschlüssel (000-999,AAA-ZZZ) eine DATEV Zahlungsbedingung (10-99) zuordnen, was rein technisch unmöglich ist, damit hätten wir dann immer noch keine Lösung für kundenspezifische Zahlungsbedingungen (Kd.-Nr. 100000 bis 139999). Ferner müssten wir auch eine Überwachung schaffen, dass jede DATEV Zahlungsbedingung nur einmal verwendet wird, d. h. hat man bisher 22 Zahlungsbedingungen eine entsprechende DATEV Zahlungsbedingung zugeordnet 10-32 und will nun die nächste anlegen, so muss man sicherstellen, dass 23 nicht irgendwo bei den Zahlungsbedingungen (000-999,AAA-ZZZ) hinterlegt ist und auch nicht bei den Kunden (100000 bis 139999), denn 2x 23 geht nur dann, wenn die Zahlungsbedingungen identisch sind, was ohnehin keinen Sinn macht.
Wir wissen mittlerweile, dass wir auch im "Belegfeld 2" die Nettofälligkeit in der Form "JJMMTT" übergeben können. Gibt es eine entsprechende Lösung auch für die Skonto Daten 1/2 und die Skontobeträge 1/2?
Wir haben vor vielen Jahren ebenfalls mit der Buchhaltungssoftware Informationen über Zahlungbedingungsschlüssel ausgetauscht und mussten damals schon erkennen, dass diese Lösung einfach zu klein gedacht ist.
Schon mal Danke für die Hilfe!
Gelöst! Gehe zu Lösung.
Das war zu schnell von mir. Im Belegfeld 2 muss die Nettofälligkeit in der Form "TTMMJJ" hinterlegt werden.
Ok, vielleicht ist ja meine Beschreibung zu umfangreich. Ich vereinfache das ganze einmal, damit ich hier nicht alleine schreibe:
Es gibt die Möglichkeit im Belegfeld 2 in der Form "TTMMJJ" fix das Datum der Nettofälligkeit zu hinterlegen.
Kann man in ähnlicher Art und Weise auch die Skontofälligkeit und den Skontobetrag als festes Datum/festen Betrag hinterlegen?
Hallo Herr Leimann,
kurz und knapp: nein
Zum Buchungssatz selbst wird nur die Fälligkeit anhand des Belegfeldes 2 bzw. die Fälligkeit in den OPOS-Informationen gespeichert.
Die übrigen Methoden zur Fälligkeitsermittlung (Zahlungsbedingungen) werden vom Programm errechnet.
Viele Grüße
Christian Wielgoß
Guten Morgen Herr Wielgoß,
das hatte ich mir schon gedacht, desshalb habe ich das auch mal als richtige Antwort markiert.
Das mag ja bei der DATEV Tradition haben, sinnvoll ist das allerdings nicht.
Beispiel:
Ein Mandant errechnet die Fälligkeit bei 30 Tagen netto falsch, z. B. Rechnungsdatum 01.02.2019, darauf ausgewiesene Fälligkeit 01.03.2019 und übergibt dies über den Fälligkeitsschlüssel 10, der 30 Tage Nettofälligkeit vorsieht. Dann würde die DATEV-Anwendung aber als Fälligkeitsdatum den 03.03.2019 errechen, was rechnerisch korrekt wäre, die auf der Rechnungs ausgewiesene - nach dem Kalender bestimmbare Fälligkeit - wäre aber der 01.03.2019, am 03.03.2019 befindet sich der Schuldner bereits im Verzug. Vorausgesetzt, die Rechnung enthält eine Satz wie: "Verzug tritt ohne Mahnung ein."
Es mag nicht darauf ankommen, maßgeblich sollte aber die auf dem Beleg ausgewiesene Fälligkeit sein, die man so schlecht abbilden kann.
Was wäre denn, wenn ein Mandant eine Rechnung erstellt, die 1.000€ netto und 1.200€ brutto vorsieht und die Rechnung mit 1.200€ und Mehrwertsteuerkennzeichen 19% an die DATEV-Anwendung übergibt?
Es sollte immer nur eine Anwendung maßgeblich sein.