Table of Contents

Häufige Supportthemen (FAQ)

Warum wird mit Debitoren- und Kreditorenrechnungen kein Skontobetrag übertragen?

Die von der DATEV vorgegebene Datenstruktur gestattet die Übermittlung von Skontobeträgen nur bei Zahlungsbuchungen und unter der Voraussetzung, dass in Konto und Gegenkonto ein "Geldkonto" und ein Personenkonto (Debitor/Kreditor) angegeben sind. Daher kann bei Rechnungen kein möglicher Skontobetrag übertragen werden.

Bei den Buchungssätzen von Zahlungsein- und Zahlungsausgängen ergeben sich andere Beträge, als ursprünglich in Dynamics NAV/Business Central gebucht wurde.

Entweder erfolgten die Buchungen in Dynamics NAV/Business Central ohne die Belegart „Zahlung" oder im Kontenplan ist die Zuordnung der "DATEV Kontoart" mit der Option "Geldkonto" unvollständig.

Der DATEV-Dienstleister beanstandet, dass für einen Beleg mehrere Posten bei dem Debitor bzw. Kreditor in der DATEV-Software entstehen bzw. die Verkehrszahlen bei Einkauf mit Erwerbssteuer bzw. §13b UStG nicht passen.

Beim Import in die DATEV-Software gibt es eine Möglichkeit einzustellen, dass Belege mit identischer Belegnr. und Personenkontonr. zu einem Posten zusammengefasst werden.
Alternativ dazu kann in der DATEV Einrichtung die Option "Verhindere Belegaufteilung" gesetzt werden.

In Buchungssätzen von Rechnungen bzw. Gutschriften wird der DATEV keine Information über mögliche Skontoabzüge übermittelt.

Skonto kann der DATEV-Software nur bei Zahlungsbuchungen übertragen werden. Bei Rechnungen oder Gutschriften sind solche Daten von der DATEV nicht vorgesehen. Skontokonditionen werden daher ausschließlich mit den Debitoren- bzw. Kreditorenstammdaten übertragen.

Buchungen nach §13b UStG werden nicht mit den korrekten Buchungsschlüsseln 46, 91, 92, 94 oder 95 an die DATEV übertragen.

Buchungen dieser Art müssen in Dynamics NAV/Business Central auf ein Konto erfolgen, das in der Spalte "DATEV Kontoart" des Kontenplans auf "Automatikkonto" gesetzt ist und auch in der DATEV-Software diese Funktion hat. In Dynamics NAV/Business Central hängt die Abbildung der §13b-Buchungen von der individuellen Einstellung seitens des Anwenders ab und ist zumeist wie ein Sonderfall der Erwerbssteuer gelöst. Daher gibt es keine Möglichkeit, diese Posten von solchen mit echter Erwerbssteuer oder normaler Mehrwertsteuer zu unterscheiden. Bei Verwendung eines Kontos mit Automatikfunktion stellt sich diese Problematik nicht.

Der DATEV-Dienstleister reklamiert, dass in den Buchungssätzen keine Steuerschlüssel enthalten sind bzw. die Automatikfunktionen der Konten deaktiviert werden, weshalb eine UVA nicht möglich ist.

Bei Exporten mit Nettobeträgen werden die Automatikfunktionen immer deaktiviert, da sonst die DATEV-Software aus einem Nettobetrag ein weiteres Mal die Mehrwertsteuer berechnen würde. Ist eine UVA aus der DATEV-Software erforderlich, muss die Option "Bruttoexport" in den Einrichtungsdaten gesetzt werden.

Es sollen keine Stammdaten an die DATEV übermittelt werden.

Erfassen Sie jeweils drei zusätzliche Stammdatensätze, getrennt für inländische, ausländische mit USt.-ID-Nr. und drittländische Debitoren/Kreditoren. Hinterlegen Sie unter "DATEV Kontonr." bei allen Debitoren/Kreditoren eine dieser drei zusätzlichen Debitor-/Kreditor-Nummern entsprechend dem Sachzusammenhang. Deaktivieren Sie in der "SIEVERS DATEV Einrichtung Karte" die Optionen "Debitorenstamm" und "Kreditorenstamm". Informieren Sie den DATEV-Dienstleister, damit dieser die zusätzlichen Personenkonten ebenfalls in seine Software einpflegt.

Dieses Vorgehen ist erforderlich, da die DATEV-Software keine Direktbuchungen auf den Sammelkonten für Forderungen und Verbindlichkeiten zulässt, sondern stets eine Personenkontonr. erwartet, und in den Buchungssätzen keine USt.-ID-Nr. enthalten ist.
Da hierbei immer jeweils drei Pseudo-Debitoren/-Kreditoren eingesetzt werden, ist es dem DATEV-Dienstleister nicht möglich, eine korrekte Zusammenfassende Meldung zu erstellen.

Der DATEV-Dienstleister reklamiert, dass in den Buchungssätzen keine individuellen Steuerschlüssel (50-59, 70-79) enthalten sind.

Bei den individuellen Steuerschlüsseln 50-59 und 70-79 handelt es sich um Schlüssel für zumeist ausländische Steuersätze, die der DATEV-Dienstleister mandantenabhängig in den Stammdaten seiner Software einrichtet und mit den gewünschten Funktionen und Steuersätzen versieht. Über die Funktionsweise und zugeordneten Steuersätze gibt es von Seiten der DATEV keine Festlegung und sie kann daher stark variieren.

Ferner ist bei Verwendung dieser Schlüssel die Übertragung eines individuellen Steuersatzes erforderlich. Das ist eine Information, die Dynamics NAV/Business Central im Ursprung nicht enthält (exakt: die Unterscheidung zwischen gesetzlichen und individuellen Steuersätzen). In der MwSt.-Buchungsmatrix können zwar unterschiedliche Steuersätze hinterlegt werden, nicht jedoch ein standardisiertes Unterscheidungsmerkmal bezüglich gesetzlich und individuell. Der DATEV-Dienstleister hat die Möglichkeit, diese Schlüssel manuell nach dem Import in die DATEV-Primanota nachzutragen.

Alternativ dazu hat der DATEV-Dienstleister die Möglichkeit, individuelle automatische Konten einzurichten. Buchungssätze auf diese Konten können ohne Steuerschlüssel und ohne individuellen Steuersatz übertragen werden.

Posten, deren Aufbewahrungsfrist abgelaufen sind, sollen mit Hilfe der Datumskomprimierung komprimiert werden.

Wenn Sachposten komprimiert werden, entstehen neue zusammengefasste Sachposten. Diese lassen sich in der Regel exportieren. Anders sieht es bei der Komprimierung von Debitoren- und Kreditorenposten aus. Hierbei entstehen ebenfalls neue zusammengefasste Sachposten mit dem eingestellten Arbeitsdatum als Buchungsdatum.

Achten Sie darauf, dass es bereits einen DATEV Export für diesen Tag gibt, um Fehler zu vermeiden.

Die exportierte Belegnummer ist immer falsch und enthält Leerstellen.

Dieses Problem tritt auf, wenn unzulässige Zeichen in der Belegnummer verwendet wurden. Weitere Informationen finden Sie im Abschnitt "Besondere Konventionen der DATEV".

In den Exportposten entstehen willkürlich erscheinende Buchungssätze, obwohl die Salden der Konten korrekt bleiben.

Wird in Dynamics NAV/Business Central ein FiBu-Buchungsblatt verwendet, dessen Buchungsblatt-Vorlage nicht mit der Einrichtung "Saldo pro Beleg abstimmen" versehen ist, dürfen nach Soll und Haben sachlich zusammengehörende Buchungen nicht durch andere Buchungsblattzeilen getrennt werden. Andernfalls ist es nicht möglich, Konto und Gegenkonto sachlich korrekt zu bestimmen.

Der Bruttoexport meiner Abgrenzungsbuchungen ist falsch.

Ist an der Abgrenzungsvorlage als Startdatum für die Abgrenzung das "Buchungsdatum" hinterlegt, bucht das System die erste Abgrenzung mit der gleichen Transaktionsnummer wie den abzugrenzenden Beleg. Dadurch wird der Bruttoexport fehlerhaft. Um die Buchungen richtig zu exportieren muss das Feld "Verhindere Belegaufteilung" in der DATEV Einrichtung Karte aktiviert und ein Saldenverrechnungskonto hinterlegt werden.

DATEV Exportprotokoll: Satznr. XX: Die Kontonr. / Gegenkontonr. darf nicht leer sein.

Die Satznr. finden Sie in der "SIEVERS DATEV Exportposten Übersicht". Allerdings entsteht der Fehler i.d.R. schon bei einer vorherigen Buchung und nicht explizit bei der Buchung, der das Konto / Gegenkonto fehlt. Die häufigste Ursache für diesen Eintrag im Exportprotokoll sind Splittbuchungen. Bei vielen der gemeldeten Fälle ist Continia OPplus im Einsatz. Um Splittbuchungen beim Zlg. Export i.V.m. dem Modul zu vermeiden ist es erforderlich, dass das Feld "Gegenkonto pro Zahlungszeile" in der "Zahlungsbuchungsmatrix" für alle Zeilen aktiviert wird. Splittbuchung lassen sich nur mit dem in der SIEVERS DATEV Einrichtung Karte für den Export hinterlegtem Verrechnungskonto ("Verrechnungs Kontonr.") exportieren.

Hinweis

Ein weiterer Grund für diese Meldung kann eine Direktbuchung auf ein Steuerkonto sein. Direktbuchungen auf Sachkonten mit der DATEV Kontoart "MwSt.-Konto" führen beim Bruttoexport zu einem leeren Gegenkonto. Sie könnnen die Buchungen mit dem Verrechnungskonto exportieren. Die Buchung muss bei der Verarbeitung des Stapels in DATEV korrigiert werden.

DATEV Exportprotokoll: Es wurden mehr Buchungssätze erstellt, als geschrieben.

Häufig tritt die Abweichung i.V.m. dem "fehlenden Konto/Gegenkonto" auf. Demnach sind auch hier i.d.R. Splittbuchungen die Ursache, welche sich nur mit dem Saldenverrechnungskonto exportieren lassen.

Statt der Debitornummer / Kreditornummer wird das Sammelkonto in der Exportdatei ausgegeben.

Der Grund dafür ist die fehlende "DATEV Kontoart" am jeweiligen Sammelkonto. Ist die Option im "SIEVERS DATEV Kontenplan Einrichtungsassistent" in "rot" dargestellt, hat sie keinen Einfluss auf den Export. In dem Fall muss die Funktion "In den Kontenplan übertragen" ausgeführt werden.

Der DATEV-Dienstleister reklamiert, dass die bereitgestellte Datei nicht in DATEV eingelesen werden kann.

Wird die erstellte Exportdatei vor der Bereitstellung an den DATEV-Dienstleister oder durch den DATEV-Dienstleister geöffent, kann das dazu führen, dass die von Microsoft Excel konvertiert wird. Nach dem Konvertieren ist sie für die DATEV Anwendung nicht mehr lesbar.

Warum erhalte ich beim Buchen über das Fibu Buch.-Blatt einen Fehler bzgl. der maximalen Buchungsbeschreibung von 60 Zeichen, obwohl das Feld "Buchungsbeschreibung mit mehr als 60 Zeichen kürzen" in der "DATEV Einrichtung Karte" aktiviert ist?

Sofern mehrere DATEV Einrichtungen angelegt wurden, muss das Feld zwingend in jeder dieser Einrichtungen aktiviert werden.