AMEISE EXPORT DATEV Schnittstelle Fehlerhaft

[dkzmyne]

Das Feld 010 Belegdatum muss laut DATEV immer 4 Stellig sein, wird durch die AMEISE aber 6 Stellig ausgegeben. Das führt zu Fehlern beim Import in LEXWARE!




DATEV Richtlinie:

https://developer.datev.de/datev/platform/de/dtvf/formate/buchungsstapel

010

Belegdatum

^(\d{4})$

Format: TTMM, z.B. 0105 Das Jahr wird immer aus dem Feld 13 des Headers ermittelt

 

[Enrico W.]

Also der Ameisenexport für DATEV ist - nun ja - für DATEV gemacht. Und da passen die Daten meines Wissens. Auch sollte es da keine Änderungen in der letzten Zeit gegeben haben, zumal wir den Rechnungsdatenservice haben.

 

[Jens Falk]

Das Feld 010 Belegdatum muss laut DATEV immer 4 Stellig sein, wird durch die AMEISE aber 6 Stellig ausgegeben. Das führt zu Fehlern beim Import in LEXWARE!




DATEV Richtlinie:

https://developer.datev.de/datev/platform/de/dtvf/formate/buchungsstapel

010

Belegdatum

^(\d{4})$

Format: TTMM, z.B. 0105 Das Jahr wird immer aus dem Feld 13 des Headers ermittelt

JTL erstellt keinen korrekten DATEV-Export (Das habe ich mehrfach bei Partnertreffen, Connect und beim PO angesprochen) und Lexware liest deshalb den Export nicht ein, sondern gibt eine Fehlermeldung aus, daß das Format nicht stimmt. Datev liest den JTL-Datev-Export ein, weil fehlertoleranter. Lexware hat sich entschieden vollständig den Datev-Standard einzuhalten. Dafür gibt es den ASCII Import in Lexware.

Nachstellen kann man das einfach indem man in Lexware einen Datev-Export erstellt und diesen mit dem JTL-DATEV-Export vergleicht.

Es gibt zwei Lösungen.

1.) Man erstellt einen Ameisen-Export CSV (Buchungsdaten --> Rechnungsdaten), benennt dabei die Felder so wie sie bei Lexware heisßen und importiert diesen in Lexware.
2.) Man exportiert mit der Ameise mittels alten DATEV- Format (abgekündigt) und bedient sich eines Zusatz-Tools, wie DaWan von MohrIT (https://www.mohr-it.de/dawan/). Hier wird eine korrekte DATEV-Datei erstellt, die dann auch Lexware importierrt.

Die Frage, die sich mir bei Deiner Frage stellt: Welche Lexware-Version ist im Einsatz, die sagt, daß das Belegdatum falsch sei?

 

[dkzmyne]

Die Frage, die sich mir bei Deiner Frage stellt: Welche Lexware-Version ist im Einsatz, die sagt, daß das Belegdatum falsch sei?

Der Lexware Support hat das herausgearbeitet, und getestet.

Der JTL Support hat dann: im toptions die Einstellung Ameise.Datev.DateFormat auf ddMM geändert, was nun dazu führt das die Spalte
Belegdatum = OK (z.b. 2212) ist
aber die letzten beiden Spalten:
Leistungsdatum, Datum Zuord.Steuerperiode
auch 2212 haben, diese aber 22122023 haben müssten. Dann würde der Import gehen.

 

[Jens Falk]

Der Lexware Support hat das herausgearbeitet, und getestet.

Der JTL Support hat dann: im toptions die Einstellung Ameise.Datev.DateFormat auf ddMM geändert, was nun dazu führt das die Spalte
Belegdatum = OK (z.b. 2212) ist
aber die letzten beiden Spalten:
Leistungsdatum, Datum Zuord.Steuerperiode
auch 2212 haben, diese aber 22122023 haben müssten. Dann würde der Import gehen.

Hallo,

kannst du mir bitte das Lexware-Ticket per PN übermitteln, Danke.

 

[net97]

Moin,
ich häng mich da mal dran. Wir würden die Rechnungen auch gerne über den DATEV-Import in Lexware importieren.
Geht zwar auch über den "normalen" CSV-Export, wäre aber so komfortabler.

 

[Jens Falk]

Moin,
ich häng mich da mal dran. Wir würden die Rechnungen auch gerne über den DATEV-Import in Lexware importieren.
Geht zwar auch über den "normalen" CSV-Export, wäre aber so komfortabler.

Wieso? Den datev-Import muß Du zweimal bestätigen. Der csv-Import geht sofort in den Stapel.

 

[John]

Ich finde, die gesamte Diskussion ob CSV auch geht oder wie man DATEV nachbearbeiten kann, geht doch am Problem vorbei:

Wenn es einen DATEV Standard gibt, wieso hält sich JTL nicht daran?

 

[Jens Falk]

Ich finde, die gesamte Diskussion ob CSV auch geht oder wie man DATEV nachbearbeiten kann, geht doch am Problem vorbei:

Wenn es einen DATEV Standard gibt, wieso hält sich JTL nicht daran?

Weil mutmasslich schlicht die Zeit fehlt. Und da, weil fehlertoleranter, der Import in DATEV klappt, keine Notwenigkeit gesehen wird. Da kann ich fast zustimmen, der csv-Import klappt doch auch. Was will man denn mehr?