In Bearbeitung Rabatte werden in den Exports falsch behandelt.

[patoc]

weil einige jetzt schon irgendwie mit gutscheinen umgehen (obwohl die gutscheinverealtung noch nicht implementiert), wurde das als zahlart eingeführt. daher auch der "workaround" mit den buchungen von unbaren zahlungen über die kasse und den geldtransit.

okay, Gutscheine nutzen wir auch, daher hatte ich das in diesem Thread auch angesprochen. Hast Du schon Erfahrungen, was es ausmacht, wenn man den Schalter aktiviert?

LG

 

[patoc]

Das obere Beispiel zeigt, wie Ihr das im September gemacht habt: Als "Warenverkauf Kartenzahlung" bezeichnet und die Konten für (hier) die EC-Karte (1461) und den Warenverkauf 5% (4302) angesprochen. Sehr gut!

Wenigstens die Bezeichnung hätte man ja mal beibehalten können ("Warenverkauf Kartenzahlung"). Denn so sieht man der Buchung überhaupt nicht mehr an, dass sie eigentlich unbar ist, obwohl sie auf das Bar-Konto der Kasse (1600) gebucht wird. ;-(

LG

 

[patoc]

Hallo Janusch,

das ist ja generell nachvollziehbar gedacht von Euch:

Man kann in den Einstellungen statt SKR04 1600 dann 1460 eintragen dann wird es so ausgegeben, ich weiß nur nicht ob das korrekt ist.

ABER: Dann hättet Ihr die Möglichkeit schaffen müssen, hier ZWEI Konten zu hinterlegen: 1. Das Kassenkonto (bar) -> 1600 und 2. das Tranferkonto -> 1460. Dann hätte es funktioniert.

So haben wir nun den Kuddelmuddel, dass bare und unbare Zahlungen auf das Kassenkonto laufen (1600) und zwischen bar und unbar nicht unterschieden werden kann.

Ich denke, wenn Ihr dieses zweite Konto konfigurierbar machen würdet, wäre das mindestens schon die halbe Miete wenn nicht sogar mehr.

@ofenheizer: Was meinst Du?

LG

 

[ofenheizer]

Naja, ich hatte meine Meinung dazu schon geschrieben, ich hätte diesen "hack" einfach nicht gemacht und gut ist. die gutscheinverwaltung wird kommen, da heisst es für alle, die sowas brauchen, eben warten.
so wi ich janusch verstand habe, tauchen diese buchungen auch nur im datev-export auf und berühren sonst nichts weiter.
ich werde bei mir jedenfalls das datev-buchungskonto nicht auf das kassenkonto ändern, sondern so belassen, wie es war.

 

[patoc]

Hallo Janusch,

was uns gerade auch noch auffällt: Unsere selbst definierte "Zahlart" Gutschein wird jetzt nicht mehr differenziert behandelt:



Der zugehörige Einkauf schaut so aus:





-> 16 EUR Umsatz (neuerdings voll auf Kasse gebucht, 1600), davon werden 15 EUR über Gutschein bezahlt. Diese 15 EUR müssen aus der Kasse wieder raus (1600).

So bleibt uns quasi keine andere Möglichkeit mehr, als alle Buchungen, die mit "Geldtransit" beginnen im Gegenkonto auf 1600 statt 1460 zu ersetzen. Sonst stimmt ja die Kasse nicht mehr.

Im Kassenbuch behandelt Ihr das richtig:



Im DATEV-Export aber eben nicht, denn da bleiben nun volle 16 EUR in der Kasse (1600) stehen. Gleicht Ihr die beiden Exports nicht ab bevor Ihr die freigebt?

Wie sollen wir nun damit umgehen?

LG

 

[patoc]

so wi ich janusch verstand habe, tauchen diese buchungen auch nur im datev-export auf und berühren sonst nichts weiter.

...naja, aber damit ist der DATEV-Import ja falsch und damit der Monatsabschluss ;-(

Das ist echt inkonsistent so.

LG

 

[schnitzel112]

Ihr könnt das Transitkonto über die DATEV Einstellungen einstellen. Hier bietet es sich an das Kassenkonto (Konto der Zahlart Bar) einzutragen.
Ich hatte vorgeschlagen einfach das Konto der Barzahlart zu nehmen statt das extra Konto in den Datev einstellungen um genau die verwirrung hier zu verhindern

 

[patoc]

Hallo trummerjo,

vielen Dank für den Tipp. Aber genau da haben wir ja das (korrekte) Transitkonto 1460 eingetragen. Hier ein Kassenkonto (1600 etc.) einzutragen macht es ja noch intransparenter. Aber klar, das ist natürlich eine Lösung - nur dann vom Steuerprüfer sicher nicht nachvollziehbar ;-(




@Janusch: Was gedenkt JTL hier denn zu tun? Bleibt das jetzt so (falsch)? Ursprünglich ging es ja "nur" um das Thema Splitbuchungen und Gutscheine. Dass deswegen nun alle unbaren Zahlungen erst mal ins bare Kassenkonto gebucht werden war ja nicht die Idee.

LG

 

[patoc]

Hallo zusammen,

JTL / Janusch scheinen sich hier ja leider bedeckt zu halten.

Vom Gutschein-Thema abgesehen ergibt sich aus meiner Sicht an der folgenden Stelle Handlungsbedarf um einen korrekten DATEV-Export zu erreichen:





1. Im Buchungstext sollte nach bar und unbar unterschieden werden, so wie es im September noch der Fall war: a) Warenverkauf BAR, b) Warenverkauf Kartenzahlung
2. Das Gegenkonto eines unbaren Warenverkaufs darf kein Kassenkonto sein, sondern sinnvollerweise das definierte DATEV-Transitkonto (s.o.) - in unserem Beispiel wäre das 1460
3. Im Falle eines Zahlungs-Splits sollte dieser ebenfalls aufgesplittet werden in den baren und unbaren Teil, der Transit dann wieder über das korrekte Transitkonto
-> im obigen Beispiel hieße das:

4302 | 1600 1 EUR Warenverkauf BAR
4302 | 1460 15 EUR Warenverkauf Gutschein
4102 | 1460 -15 EUR Geldtransit Gutschein einlösen

-> so wären richtigerweise 16 EUR auf den Warenumsatz gebucht (4302), davon bleibt 1 EUR in der Kasse als barer Bestand und die 15 EUR laufen über zwei saubere Buchungen via Transitkonto (1460) auf das (hier) Gutschein-Konto.

@Janusch: Wie schaut's aus?

LG

 

[schnitzel112]

Welches Konto hast du denn in den Zahlungsarten hinterlegt?
Ohne Spaltennamen lassen sich deine Screenshots schwer entziffern

 

[patoc]

...so, wir haben nun in den sauren Apfel gebissen und bei der DATEV-Konfiguration überall das Konto auf die jeweiligen Kassenkonten geändert (1600, 1610, 1611 etc.). Unsauber vom Transferkonto her, aber im Ergebnis halbwegs okay.

Wo es noch nicht stimmt ist bei Splitzahlungen: (siehe oben)



Aus der Buchung mit "Gutschein einlösen, BAR" müssten zwei Buchungen gemacht werden (s.o.), 15 EUR via Gutschein und 1 EUR via BAR - dann würde das passen.

@trummerjo: Wir haben für die Zahlarten Karte, Gutschein die Konten 1461, 1462, 4102 angelegt. Die Kassenkonten sind 1600, 1610, 1611. Das DATEV-Konto für Einzahlungen bei der Bank ist 1460. Und ursprünglich ebenfalls hinterlegt war 1460 als DATEV-Transferkonto allgemein. Letzteres haben wir ja jetzt (unsauber) auf die Kassenkonten (16xx) geändert. LG

 

[schnitzel112]

Aus der Buchung mit "Gutschein einlösen, BAR" müssten zwei Buchungen gemacht werden (s.o.), 15 EUR via Gutschein und 1 EUR via BAR - dann würde das passen.

Also das passt doch. Es wir erst in die Kasse gebucht mit 16 EUR und dann aus der 15 EUR Kasse auf das Transitkonto der Zahlungsart (4102)? Somit ist 1 EUR Bar und 15 EUR Gutschein.

Den Umweg über die Kasse geht man ja, da ein Bon unterschiedliche Steuersätze haben kann. Ich war auch erst skeptisch finde die Lösung aber mittlerweile gut.

 

[patoc]

Nein, das passt leider eben nicht!

Es schaut nur so aus, weil jetzt alles mit 1600 in einen Topf geworfen wird. Bar und unbar.

De facto muss es für DATEV aber klar sein, was bar und was unbar ist. Das sind völlig unterschiedliche Konten in der Buchhaltung.

Daher muss diese Kombibuchung "Gutschein einlösen, BAR" aufgesplittet werden in BAR 1 EUR und UNBAR 15 EUR. Dann gleichen sich 15 EUR UNBAR aus und der 1 EUR BAR bleibt richtigerweise in der Kasse stehen. So muss es JTL intern ja sogar schon machen, sonst würde das Kassenbuch ja nicht stimmen.

Und ja, ich stimme Dir zu: Entweder man lässt das für die restlichen Thema so und wir nutzen unsauber 16xx oder JTL fügt das oben von mir angeregte zusätzliche Transit-Konto ein. Aber vor da wieder was verschlimmbessert wird denke ich auch, dass wir es lieber so belassen.

Somit bleibt im Moment für mich nur die Trennung der baren versus unbaren Zahlungen stehen.

LG

 

[patoc]

Hallo Janusch,

wir haben einen weiteren Fehler im DATEV-Export gefunden. Mindestens ein Storno wurde nicht korrekt berücksichtigt.



Auf dem Tagesabschluss steht der Storno zwar drauf, er wird in der Summenberechnung aber ignoriert. Rauskommen müssten eigentlich 324,96 EUR - und nicht 334,62 EUR (BAR).

Im DATEV-Export scheint es korrekt zu sein (auch wenn ich hier die Originalbuchung und den Storno erwarten würde, beides fehlt im DATEV-Export):



Das Kassenbuch hingegen ist so falsch wie der Tagesabschluss, da hier der Storno fehlt - dafür steht im Kassenbuch noch (die zu stornierende) Originalbuchung:



Hier gibt es also offensichtlich Inkonsistenzen - und das schon vor den Exports.

Kennt Ihr diesen Bug schon?

Beste Grüße und Dank!

 

[patoc]

Nein, das passt leider eben nicht!

Es schaut nur so aus, weil jetzt alles mit 1600 in einen Topf geworfen wird. Bar und unbar.

De facto muss es für DATEV aber klar sein, was bar und was unbar ist. Das sind völlig unterschiedliche Konten in der Buchhaltung.

Daher muss diese Kombibuchung "Gutschein einlösen, BAR" aufgesplittet werden in BAR 1 EUR und UNBAR 15 EUR. Dann gleichen sich 15 EUR UNBAR aus und der 1 EUR BAR bleibt richtigerweise in der Kasse stehen. So muss es JTL intern ja sogar schon machen, sonst würde das Kassenbuch ja nicht stimmen.

Und ja, ich stimme Dir zu: Entweder man lässt das für die restlichen Thema so und wir nutzen unsauber 16xx oder JTL fügt das oben von mir angeregte zusätzliche Transit-Konto ein. Aber vor da wieder was verschlimmbessert wird denke ich auch, dass wir es lieber so belassen.

Somit bleibt im Moment für mich nur die Trennung der baren versus unbaren Zahlungen stehen.

LG

-> Hier haben wir uns jetzt mit einem Workaround beholfen: Wir nehmen die Kombi Gutschein/Bar als BAR an, so auch den folgenden Transit. Die Kombi Gutschein/Unbar nehmen wir als UNBAR an, so auch den folgenden Transit. Dann lässt ich das für uns gut auflösen. Das passt auch mit gemischten Steuersätzen. Gott sei Dank hatten wir bisher noch nicht die Kombi Gutschein/Bar/Unbar... dann müssten wir wieder kreativ werden

LG

 

[patoc]

Hallo Janusch,

hier noch ein Bug. Ein Kunde hat mit einem 15-EUR-Gutschein gezahlt. Der Einkauf hat aber nur 14,90 EUR gekostet. Die Kassiererin hat 0,10 EUR Rückgeld gegeben (was sie gar nicht darf, aber das ist ein anderes Thema....).

Auf dem Tagesabschluss tauchen diesen 10 Cent auf:



Im Kassenbuch auch:



ABER, im DATEV-Export steht:



Daraus wird aber nicht klar, dass hier BAR 10 ct herausgegeben wurden.

LGP

 

[patoc]

Nachdem dieser Bug auch operativ gestern wieder aufgekommen ist, habe ich hierzu einen extra Thread aufgemacht: https://forum.jtl-software.de/threa...nd-datev-export-nicht-beruecksichtigt.141671/

@Janusch / JTL: Von Euch kommt ja gar keine Antwort mehr... habt Ihr so viel zu tun? Oder lest / kommentiert Ihr hier nicht mehr mit. Das wäre gut zu wissen, denn dann würde ich mich direkt an den Support wenden. Bitte um kurzes Feedback! LGP

Hallo Janusch,

wir haben einen weiteren Fehler im DATEV-Export gefunden. Mindestens ein Storno wurde nicht korrekt berücksichtigt.

Den Anhang 50495 betrachten

Auf dem Tagesabschluss steht der Storno zwar drauf, er wird in der Summenberechnung aber ignoriert. Rauskommen müssten eigentlich 324,96 EUR - und nicht 334,62 EUR (BAR).

Im DATEV-Export scheint es korrekt zu sein (auch wenn ich hier die Originalbuchung und den Storno erwarten würde, beides fehlt im DATEV-Export):

Den Anhang 50492 betrachten

Das Kassenbuch hingegen ist so falsch wie der Tagesabschluss, da hier der Storno fehlt - dafür steht im Kassenbuch noch (die zu stornierende) Originalbuchung:

Den Anhang 50489 betrachten

Hier gibt es also offensichtlich Inkonsistenzen - und das schon vor den Exports.

Kennt Ihr diesen Bug schon?

Beste Grüße und Dank!

 

[Janusch]

Hallo,
ja aktuell massig zu tun, deshalb konnte ich leider kaum ins Forum. Das Thema wird hauptsächlich von mir betreut und ich muss hier mit externen Beratern Rücksprache halten, bin da leider kein Fachmann.

Die Änderung im Export wurde uns empfohlen, da so die wenigsten Fehler passieren können. Der Gesamtumsatz läuft komplett über Kasse und für Unbare Zahlungen wird dann von Kasse auf die Transitkonten gebucht.

Für den Datev-Export, eine EC Zahlung wenn Kasse als Konto stehenbleibt:

               53,15€ H             4400 an 1600
               53,15€ S              1461 an 1600

So spielt das S/H im Export eine Wichtige Rolle. Da hier die Header und S/H angaben fehlen, kann ich nicht genau sagen was da in den Screens nicht stimmt.
Laut unserer Beratung sollte der Export wie folgt ausschauen:

Beleg R-0089 -> Ein Verkauf von 7 und 19% Waren und Bezahlung mit Gutschein 20€ und Rest mit EC-Karte.
Beleg R-0090 ist ein Bsp. für eine Zahlung mit 25€ Gutschein Rest Bar
Beleg R-0091 ist ein Bsp. für eine Zahlung mit 25€EC und Rest Bar

Hoffe das Hilft.

Das Problem mit Storno versuche ich nachzustellen.

Bei dem Gutschein und BAR - Rückgabe, da fehlen bei Datev-Screen die Beträge, an sich müssten diese beiden gleich sein. Der Fall könnte auch eintreten das man den Restwert vom Gutschein dem Kunden auszahlt.
Ich mache mich schlau wie man das angehen könnte.

 

[Janusch]

Halo,
bei Storno kann ich kein Problem finden, bei mir ist alles korrekt:


Könnte es sein, das die Retoure bearbeitet wurde und die Menge statt -1 auf 1 gesetzt wurde?
Der Beleg 1825-VA1 sollte denke ich die Retoure sein, aber da steht Barverkauf, deshalb die Vermutung.

 

[patoc]

Hallo Janusch,

bitte entschuldige meine Sendepause - das Weihnachtsgeschäft hat uns überrollt...

Ja, das mit dem Storno war ein Interpretationsfehler - das hatte ich auch mit Lars W. schon besprochen. Die irreführenden Begriffe anzupassen hatte ich angeregt, aber das war seitens JTL nicht erwünscht. Ich habe nun eine "Handlungsanweisung" an unsere VerkäuferInnen ausgegeben und das richtige Vorgehen dokumentiert - hoffen wir nun mal auf das Beste.

Beim letzten Monatsabschluss sind mir unter anderen zwei Punkt aufgefallen:
1. Wählt man in der Bon-Ansicht "Anzeige Bons letzter Monat" werden aber die Bons vom aktuellen Monat gezeigt -das ist mir so in der Vergangenheit nicht aufgefallen. Hat sich da ein Bug in ein Update gemogelt?
2. Vergibt man einem Kunden eine Kundenadresse wird der Bon nicht im DATEV-Export ausgegeben, sondern nur im BON-Export (z.B. B-002863-HK1, 17.11.20) - kannst Du das nachstellen, oder brauchst Du "Material" von mir?

Der letztgenannte Fehler sollte bitte in jedem Fall eliminiert werden. Was mir beim Export aus der Wawi für die Ausgangsrechnungen aufgefallen ist: Diese spezifische und noch ein paar andere POS-Rechnungen haben es aufgrund der Kundenadresse (und damit dem geänderten Kundenstatus, also von Laufkunde auf z.B. Firmenkunde) in den Export geschafft. Da es aber POS-Rechnungen sind sollte das nicht passieren. Wie gesagt, dafür fehlt mindestens eine der Rechnungen im POS-Datev-Export. Hier gibt es ggf. ein Zuordnungsthema.

Beste Grüße und Dank!