Neu AMEISE 1.4.24.1 - DATEV - Export Datum inkorrekt?

[DITH-Shop]

Moin,
ist da bei mir was falsch eingestellt, oder macht die AMEISE da tatsächlich Mist?

Ich habe einen Auftrag der über Weihnachten 2018 angelegt wurde, bezahlt wurde der Auftrag am 28.12.2018 - wegen der Urlaubstage wurde die Ware dann am 03.01.2019 versendet. (Rechnungserstellung bei Versand, also auch am 03.01.2019)

Die Ameise (Einstellung Zahlungsdatum beachten = IST) exportiert das Erstellungsdatum der Rechnung mit "0301" - anstatt das Zahlungsdatum "2812"
Da die Zahlung in 2018 eingegangen ist muss diese Buchung auch in 2018 erfolgen.
Das exportierte (verkürzte) Datum "0301" führt aber dazu das diese Buchung im Quartal 1/2018 mportiert wird, was völlig falsch ist.

Was mache ICH falsch, oder ist das nen Bug in der AMEISE / Datev?

(obiger Auftrag nur als Beipsiel - ich habe zig Buchungen im Q1/18 gefunden die eigentlich in Q4/18 gehören würden)

 

[Enrico W.]

Welchen Export nutzt Du da genau? Mit welcher Wawi-Version arbeitest Du?

 

[DITH-Shop]

Welchen Export nutzt Du da genau? Mit welcher Wawi-Version arbeitest Du?

Wawi: Wie schon im Thread Titel angegeben: 1.4.24.1
Export: AMEISE, "Buchungsdaten DATEV" / "Rechnungen"
Einstellungen wie abgebildet

 

[Enrico W.]

Ok, das mit der Wawi-Version im Titel hab ich übersehen. Sorry.
Die Ameise macht alles korrekt. Wenn Du "Ist Zahldatum" wählst, wird das auch korrekt eingetragen. Für solche Fälle gibt es gem. Auskunft eines Buchhalters auch einen 13. Monat. Da kann Dir aber normalerweise dein Steuerberater helfen.

 

[DITH-Shop]

Ok, das mit der Wawi-Version im Titel hab ich übersehen. Sorry.
Die Ameise macht alles korrekt. Wenn Du "Ist Zahldatum" wählst, wird das auch korrekt eingetragen. Für solche Fälle gibt es gem. Auskunft eines Buchhalters auch einen 13. Monat. Da kann Dir aber normalerweise dein Steuerberater helfen.

Dann ist da doch was falsch.
Denn es ist "Zahldatum" gewählt (s. Screen) es wird aber "Rechnungsdatum" = 0301 exportiert und nicht das Zahldatum 2812


Zusätztliches Problem ist, das die Ameise nur ein verkürztes Datum überträgt = "0301" statt "03012019" - Dann könnte das, zwar ebenso falsch, aber immerhin zu 2019 (Versanddatum) zugeordnet werden.
Der DATEV Import kann selbstredend nicht wissen das da was kommt was zu Q4/18 gehört wenn da nur die Datumsangaben von Q1 "irgendwas" kommen
Jetzt jede einzelne Buchung aus dem Export wieder von Hand heraustzufiedeln um das dann mit einem anderen Export/Import einem zusätzlichen Monat (zuzuordnen geht selbstverständlich nicht.

und - "isch 'abe gar keine' Steuerberater"
Das muss also alles direkt und korrekt funktionieren.

 

[MichaelH]

Ein ähnliches Problem gibt es aber immer schon, auch beim Export der Rechnungen, Zahlungen.

Ist keine Rechnung erstellt wird auch keine Zahlung in 12/2018 exportiert.
Wird die Rechnung im Jänner erstelllt, wird zwar die Rechnung exportiert, aber die Zahlung mit Auswahl 01/2018 nicht mehr, denn die ist ja vom 12/2018.

D.h. wer jeden Monat Rechnungen und Zahlungen exportiert vom 1. bis letzten des Vormonats verliert diese Vorkassen-Zahlungen im Export für die FIBU.

Wir lösen es so dass wir im 2019 erneut alle Zahlungen des ganzen Jahres 2018 exportieren und die FIBU so schlau ist und bereits vorhandene Zahlungen nicht mehr importiert.

 

[DITH-Shop]

Ein ähnliches Problem gibt es aber immer schon, auch beim Export der Rechnungen, Zahlungen.

Sagt mir das ich zumindest schon mal nicht der einzige mit solchen Probemen bin

 

[MichaelH]

Ja, aber der einfache Export der ZA/RE kann das auch nicht wissen. ansonsten würde es einen Export-Flag/Datum benötigen, man könnte nur noch 1 x exportieren und müsste ansonsten das Kennzeichen zurücksetzen.

Oder

Der Zahlungsexport dürfte nicht mehr nur auf die Rechnungen schauen, sondern müsste Zahlungen ohne Rechnung als "Zahlung" exportieren, das Kundenkonto/FIBU-Konto des Kunden gibt es dann schon, es müsste eine Zahlung (Guthaben) dann vorhanden sein, aber mit der Auftragsnummer statt der Rechnungsnummer.
Und das kann dann je nachdem was mit dem Auftrag passiert (Teillieferung, mehrere Rechnungen) komplizierter werden.
Da ich SOLL FIBU habe ist eine Zahlung ohne Rechnung für mich an sich auch nicht wichtig.
Und nur beim Jahreswechsel muss das entsprechend korrigiert werden.
Und da die Rechnung erst erstellt wird, wenn die Leistung erbracht wird, also im neuen Jahr, ist das aus jeder Sicht egal, Lagerbestand, Umsatz, etc. nur das Vermögen aus Bankguthaben stimmt nicht, aber auch das könnte man nötigenfalls belegen.

 

[knackig]

Ansonsten müsst ihr mit Rechnungsdatum beachten arbeiten und nicht mit Zahlungsdatum beachten.

Das sehe ich nicht so. Man kann nun mal offiziell mit IST- oder SOLL-Besteuerung arbeiten. Bei IST darf nur das Zahlungsdatum beachtet werden.
Mich stört die Vorgehensweise der WAWI beim Rechnungs-Export auch, denn wie schon geschrieben, werden nicht die Zahlungen des Monats gesehen, sondern nur die Rechnungen (auch bei der Einstellung IST-Besteuerung). Daher ich auch die Überschrift in der Ameise "Export -> Buchungsdaten" auch nicht ganz richtig . Den definitiv fehlenden Zahlungsexport habe ich schon moniert (ich glaube dem Rico) und man will sich die Vorgehensweise anschauen. Denn so wie es jetzt ist, ist es in meinen (und scheinbar nicht nur) Augen nicht ganz richtig. Wenn nun die Aussage kommt, wir sollen mit dem Rechnungs- und nicht mit dem Zahlungsdatum arbeiten, so macht die Einstellung IST/SOLL in der Ameise überhaupt keinen Sinn.

Es gibt wunderbare Workflows. Auftrag komplett bezahlt - > Zack - Rechnung ausgeben.

Das kommt bei vielen sicherlich nicht in Frage. Ich nutze Secupay AG. Hier wird der Auftrag gleich mit Bestellbestätigung als bezahlt markiert, obwohl die Zahlung erst 10 Tage nach Rechnungserstellung erfolgen soll. Hier die Rechnung gleich mit Zahlungseingang zu generieren wäre Quatsch und schlichtweg falsch.

Die Wawi MUSS zwischen Zahlungs- und Rechnungsdatum unterscheiden können und diese korrekt ausgeben. Wenn im DATEV (ich kenne die Gründe nicht, daher nur meine Meinung) nur ein Verkürztes Datum exportiert wird, scheint es nicht richtig zu sein. Um Jahreswechsel sind dann Fehler vorprogrammiert.

 

[Enrico W.]

Das Format wurde von Datev so vorgeschrieben. Das Jahr steht im Header der Datei. In der Datei steht lediglich das Belegdatum im Format TTMM. Wir prüfen das aktuell noch einmal über unsere Buchhaltung.

 

[MichaelH]

Ich denke alles lässt sich heute irgendwie abbilden, denn alle arbeiten schon viele Jahre mit der WAWI.

Wünschenswert wäre vielleicht:
Ein Export von Zahlungen deren Erstellung nicht im gleichen Monat war ?
- Aber nur Zahlung VOR Rechnung = "Vorkasse nicht im gleichen Monat wie Rechnungserstellung"

Also genau die Problematik wie oben beschrieben.
Dann hätte man eine von der WAWI erstellte Differenzliste zur Kontrolle und je nach FIBU auch zum Import / Abgleich, also die CSV wäre gleich, zeigt aber diese Differenzen reduziert auf die Zahlungen.

Die Rechnungen kommen im neuen Monat mit lt. gewählter Periode / Zeitraum.
-> Aber die Zahlungen des bereits exportierten Vormonats fehlen heute und kommen dann eben in diesem "Abgrenzungs-Export", also immer Selektion aktueller Monat (Periode) und welche Zahlungen gibt es im Vormonat (Vor-Periode die gewählt wurde) ?

 

[knackig]

In meinen Augen müsste es einen Export geben, bei dem die Zahlungen des Monats (unabhängig davon ob in dem Monat ein Auftrag oder Rechnung erstellt wurde) exportiert werden, und einen mit den Rechnungen (wie es jetzt ist). Dann wären wesentlich mehr Szenarien abgedeckt. Jetzt ist der Buchungsdatenexport bei einer IST-Besteuerung nicht ohne Weiteres nutzbar.

 

[MichaelH]

Er ist weder mit IST noch mit SOLL ohne weiteres nutzbar.