In Bearbeitung Rabatte werden in den Exports falsch behandelt.

[gärtnerd]

Hallo zusammen,
ich hätte da noch eine Nuance.
Ich habe öfters auch mal Zahlungen Gutschein/BAR oder Gutschein/Karte oder eine Teileinlösung von Gutscheinen. Daher habe ich, wie ihr auch, eigene Zahlungsart angelegt (Eigener Gutschein, EC-Karte, Gutschein Gewerbeverein etc).
So, meine MA haben jetzt die letzten Tage öfters einen Gutschein teileingelöst, was am Bon dann als "Rückgeld Gutschein" ausgewiesen wird (voller Gutscheinbetrag wird als Zahlung eingegeben). Top für die MA, die müssen nichts rechnen und den Restbetrag nur am Gutschein ausbessern.

Aber, Resümeé:
- DATEV Export stimmt (dort wird gebucht Gutscheinkonto an Warenkonto; Teileinlösungsbetrag)
- Kassenbuch stimmt nicht, weil dort (wie auch beim X/Z-Bon) die Rückzahlung Gutschein als "Rückgeld für nicht bar" ausgewiesen wird.

Ergo habe ich am Schluß des Tages zu viel Bargeld in der Kasse, weil ich natürlich den Restbetrag nicht bar rausgebe sondern am Gutschein vermerke. Und Datev und Kassenbuch stimmt wie bei euch auch nicht zusammen.

Wenn man das noch mit Karten- und Barzahlung kombiniert + Rabatte kann ich mir vorstellen was rauskommt. Da fände ich es aber von den Rundungsdifferenzen her besser das über ein Interimskonto zu buchen.

Wenn das so gewollt war ist es zumindest nicht praktikabel. Das ist wohl eher gedacht für "Geld abheben im Laden mit deiner Debitcard".

Ich bin echt froh, wenn eine vernünftige Gutscheinverwaltung kommt. Echt.

Viele Grüße!

 

[Janusch]

Hallo,

Aber wieso das so gebucht wird, kann ich auch nicht genau sagen. Ich fände es besser, wenn der Umweg über die Kasse nicht gegangen wird

das ist eine der wenigen Möglichkeiten unbare Zahlungen zu bearbeiten siehe: https://www.endriss.de/blog/blog-de...-unbaren-kartenumsaetzen-im-kassenbuch-bstbk/

Ja, genau. Wie in meinem Bild oben " Kartenzahlungen, inkl. der Gutscheinzahlungen " zu sehen ist wird hier einfach unterschiedlich vorgegangen. EC/Kredit und Split-frei Gutschein berührt das Kassenkonto gar nicht (nur 1461, 1462, 4102 auf die Umsatzkonten), ABER der "Split-Gutschein" bekommt keine Bon-Nummer und läuft aber über die Kasse (160x). Klar, da ja der volle Umsatz gegen die Kasse gebucht wird und dann natürlich der Rabatt da wieder runter muss. Aber das ist insgesamt einfach inkonsistent.

Das ist das interne Problem das jede Zahlungsart den Typ "Kartenzahlung" hat und diese werden zusammen gefasst. Somit ist Gutschein und EC-Zahlung vom gleichen Typ.
Wir müssen hier die Zahlungsarten Erweitern und ein Typ Gutschein einführen, dann wird es wieder bei gemischten EC/Gutscheinzahlungen gesplitet werden.
Da die Typen zusammengefasst werden, wird das erste Buchungskonto genommen. Hier hängt es von ab welche Zahlungsart als erste gebucht wurde. Wird der Bon mit Gutschein komplett beglichen, dann stimmt das immer.
Das Vorgehen war nie für Gutscheine von uns gedacht, deshalb kommt da jetzt soviel durcheinander.

Für das Buchen der Gutscheine Einkauf/Verkauf sehen wir diesen Weg vor:
https://apps.datev.de/dnlexka/document/5305720#D530572000020

oder siehe auch https://www.darmstadt.ihk.de/bluepr...rekte-kassenbuchfuehrung-stand-2020--data.pdf

 

[Janusch]

Zusammenfassend stelle ich also vermutend fest, dass bei reiner Gutschein-Zahlung oder in Kombination Gutschein-UNBAR (z.B. EC-Karte) alles richtig exportiert wird. Aber wenn ein Gutschein zusammen mit einer Bar-Zahlung kombiniert wird, dann a) die Bon-Nummer nicht ausgegeben wird und vor allem b) neben dem Kassenkonto nur das Geldtransitkonto 1460 angesprochen wird. Richtig wäre hier aber...

....umzuwandeln in:

Soll: 4302 | 1600 -> voller Einkaufsbetrag (22,50 EUR) -> passt
Haben: 4102 statt 1460 | 1600 Gutscheinbetrag (10,75 EUR) -> passt noch nicht

Hallo,
wir werden in der nä. Version den Export umbauen, damit es mit den Zahlungsarten klappt.
Bei dem Bsp. ist nicht ersichtlich was Konto und Gegenkonto ist.

Das ist das Ergebnis das wir mit unseren Beratern erarbeitet haben:


Bei Geldtransit wurde das Konto 1600 hinterlegt. Das Gegenkonto ist das Konto der unbaren Zahlungsart.
Dazu wird jetzt bei unbaren Zahlungsarten immer über Geldtransit gegangen.

Falls das so passt, werden wir in kürze die Version rausgeben. Bitte um kurzes Feedback.

Eine Änderung wird noch kommen, wenn echte Gutscheine implementiert sind. Diese werden beim Verkauf und Einlösen berücksichtigt.

 

[ofenheizer]

Hm. 1600 ist aber das Kassenkonto (SKR04). Ob das so gut ist. Wenn es da irgendwie zu Problemen kommt, stimmt ja bei irgendjemanden die Kasse wieder nicht. Es handelt sich ja bei EC und Gutschein um unbare Zahlungsarten, also sollte das Kassenkonto (auch als Geldtransit) nicht missbraucht werden.

 

[schnitzel112]

Das 1600 ist jetzt das Konto aus den Datev Einstellungen? Oder das Kassenkonto aus der Zahlart "Bar"?
(Ein Bar Verkauf in dem Beispiel wäre noch gut)

 

[ofenheizer]

1600 ist immer im SKR04 das Kassenkonto, das sollte dafür auch nicht in den Datev-Einstellungen hinterlegt sein, sondern das Geldtransit-Buchungskonto.
Problematisch an der Geschichte ist auch die Unterscheidung von Einzweck- und Mehrzweckgutscheinen.
Bei Einzweckgutscheinen sollte das Gegenkonto "Erhaltene Anzahlungen" sein (im SKR04 3272), bei Mehrzweckgutscheinen gibt es das Konto "Ausgegebene Geschenkgutscheine (SKR04 3786).

 

[Janusch]

Das 1600 kommt aus den datev Einstellungen:


Das ist Einstellbar, damit es an skr03 angepasst werden kann.

Hm. 1600 ist aber das Kassenkonto (SKR04). Ob das so gut ist. Wenn es da irgendwie zu Problemen kommt, stimmt ja bei irgendjemanden die Kasse wieder nicht.

Das ist korrekt, das scheint aber der einzige Weg zu sein unbare Zahlungsarten mit der Kasse buchen zu können. Das wurde uns von unserem Berater und in den Links die ich verlinkt habe beschrieben.
Bei SKR04 wäre es bei Geldtransit 1600 und 1460 siehe Seite 47 : https://www.darmstadt.ihk.de/bluepr...rekte-kassenbuchfuehrung-stand-2020--data.pdf

Problematisch an der Geschichte ist auch die Unterscheidung von Einzweck- und Mehrzweckgutscheinen.

Das ist nicht möglich, Gutscheine werden ganz anders verbucht, das was mit der Änderung erreicht wird, ist der Workaround um es abzubilden zu können.
Die korrekte Handhabung kommt erst rein, wenn wir Gutscheine eingebaut haben.

 

[ofenheizer]

Wo wird denn das Konto Geldtransit bei den Datev-Einstellungen noch benutzt? Wie gesagt, nicht das es zu Problemen kommt, wenn dort das Kassenkonto hinterlegt ist.

Das ist korrekt, das scheint aber der einzige Weg zu sein unbare Zahlungsarten mit der Kasse buchen zu können. Das wurde uns von unserem Berater und in den Links die ich verlinkt habe beschrieben.
Bei SKR04 wäre es bei Geldtransit 1600 und 1460 siehe Seite 47 : https://www.darmstadt.ihk.de/bluepr...rekte-kassenbuchfuehrung-stand-2020--data.pdf

Aber EC wird doch jetzt schon als unbare Zahlungsart mit der Kasse gebucht (Geldtransit an Erlöse)
So wie ich das jetzt verstehe, wollt ihr bei Gutschein-Zahlungen diese in die Kasse buchen und dann gleichzeitig in das Gegenkonto der Zahlungsart. Das hat dann aber auch Auswirkung auf die normale Zahlart "EC-Karte", die dann ja auch diesen Umweg nimmt.
Irgendwie nicht so elegant mit dem Kassenkonto als Transit, nur um jetzt hier einen Workaround reinzudrücken.

Status quo ist doch Gutscheine als Zahlungsart funktionieren noch nicht, es wird aber eingebaut.

 

[Janusch]

So wie ich das jetzt verstehe, wollt ihr bei Gutschein-Zahlungen diese in die Kasse buchen und dann gleichzeitig in das Gegenkonto der Zahlungsart.

Wollen nicht es war nicht vorgesehen, aber wie man sieht haben einige so einen Workflow gebaut mit dem Umweg über Zahlungsart für Gutscheine.
Bis jetzt wurde eine reine EC Zahlung direkt von Geldtransit an Erlös gebucht. Problem gab es bei einer Teil/Teilzahlung Bar/EC, hier wurde der Umsatz komplett über Kasse gebucht und Geldtransit.
Diese Unterscheidung gibt es künftig nicht mehr, jeder Bon der Komplett oder zum Teil mit unbar bezahlt wird, geht über die Kasse und Geldtransit.
Weitere Änderung ist das die Zahlungsarten nicht zusammengefasst werden. Somit ist man flexibler.

 

[ofenheizer]

Trotzdem nicht schön.
Im Kassenbuch muss dann aber auch aufgepasst werden, denn wie in Deinem verlinkten pdf auch steht, dürfen unbare Zahlungen nicht im Kassenbuch auftauchen.
Bei mehreren Zahlungsarten müsste doch, wie bei der Buchhaltung selbst, der Betrag gesplittet werden. Betrag x1 Kasse an Umsatzerlöse & Betrag x2 Geldtransit EC an Umsatz.

Wie gesagt, so richtig hundertprozentig buchalterisch sauber erscheint mir die Lösung mit Umweg Kasse nicht. Warum nimmt man nicht statt der Kasse gleich das Standard-Transitkonto (SKR04 1460) und bucht dann von dort an die anderen Transitkonten 1461 (EC) und 1462 (Gutschein). Dann würde die Kasse hier ganz aussen vor gelassen.

 

[Janusch]

Im Kassenbuch muss dann aber auch aufgepasst werden, denn wie in Deinem verlinkten pdf auch steht, dürfen unbare Zahlungen nicht im Kassenbuch auftauchen.

Ne, das hat damit nicht zu tun, das ist nur der Datensatz der für Datevexport generiert wird. Kassenbuch wird nur aus den Bar Zahlungen erstellt. Die unbaren werden dort nie auftauchen.

Bei mehreren Zahlungsarten müsste doch, wie bei der Buchhaltung selbst, der Betrag gesplittet werden. Betrag x1 Kasse an Umsatzerlöse & Betrag x2 Geldtransit EC an Umsatz.

Der Split klappt mit einer USt. im Bon, mit 2 muss es prozentual berechnet werden was das ganze sehr Komplex und zur Rundungsfehler führt. Die Krumen Beträge wird keiner Nachvollziehen können.

Wie gesagt, so richtig hundertprozentig buchalterisch sauber erscheint mir die Lösung mit Umweg Kasse nicht. Warum nimmt man nicht statt der Kasse gleich das Standard-Transitkonto (SKR04 1460) und bucht dann von dort an die anderen Transitkonten 1461 (EC) und 1462 (Gutschein). Dann würde die Kasse hier ganz aussen vor gelassen.

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

 

[ofenheizer]

Ne, das hat damit nicht zu tun, das ist nur der Datensatz der für Datevexport generiert wird. Kassenbuch wird nur aus den Bar Zahlungen erstellt. Die unbaren werden dort nie auftauchen.

OK. Woran wird das denn fest gemacht? Das Konto wird ja mit Kasse angegeben. Oder ergibt sich das dann aus der gewählten und hinterlegten Zahlungsart?

Der Split klappt mit einer USt. im Bon, mit 2 muss es prozentual berechnet werden was das ganze sehr Komplex und zur Rundungsfehler führt. Die Krumen Beträge wird keiner Nachvollziehen können.

OK, dann wird es tricky. Obwohl es auch hier regeln für das kaufmännische Runden gibt, siehe https://debitoor.de/lexikon/runden
Dann sollten auch keine krummen Beträge entstehen.

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

Naja, ein Transitkonto ist wahrscheinlich buchhalterisch "richtiger" als das Kassenkonto zu missbrauchen. Wahrscheinlich aber egal und den Händlerbeleg bzw. Gutschein lege ich ja auch erstmal in die Kasse - also wird das dann schon passen. Nur wenn es eben mal zu Fehlern kommt, stimmt dann jadie Kasse nicht.

 

[schnitzel112]

Es ist zwar richtig, dass es in eurem PDF Kassenbuch nicht auftaucht. Im Datev Kassenbuch allerdings schon.
Ich bin irgendwie auch nicht zu 100 Prozent überzeugt

Ein eigenes transitkonto fände ich bei splizahlungen auch gut. Dann muss natürlich auch noch das Kassen Konto bebucht werden.
Wenn ich nämlich nach dem neuen Verfahren in den Datev Einstellungen das Kassen Konto hinterlegt passt das. Wenn ich aber ein anderes (echtes Transitkonto) nehme und eine Bar-Zahlung involviert ist, wird das Kassenkonto nicht besucht.

Edit: Wie verhält sich das ganze denn bei Erstattungen auf eine "Kartenzahlungsart"?

 

[schnitzel112]

Ich habe jetzt nochmal Rücksprache gehalten. Für uns würde das mit dem Kassenkonto passen. Vorausgesetzt die Stornierungen und Rückzahlungen funktionieren dort auch.
Warum dann aber dieses Extra Konto in den Datev Einstellungen? Nehmt das Konto der Bar Zahlungsart und alles ist gut

 

[Janusch]

OK. Woran wird das denn fest gemacht? Das Konto wird ja mit Kasse angegeben. Oder ergibt sich das dann aus der gewählten und hinterlegten Zahlungsart?

Der Kassenbestand mit Barzahlungen wird extra protokolliert, daraus wird das Kassenbuch erzeugt.
Der Datevexport erfolgt aus den Belegen.

Warum dann aber dieses Extra Konto in den Datev Einstellungen? Nehmt das Konto der Bar Zahlungsart und alles ist gut

In der Regel würde es reichen. So können wir es besser Dokumentieren und es wird einfacher zu verstehen, als das man das mit der Zahlungsart Bar verheiratet.

 

[patoc]

Hallo Janusch,

wir sind wieder am Monatsabschluss dran...

Was uns gleich zu Beginn auffällt: Ihr handhabt unbare / Kartenzahlung nun sehr merkwürdig:



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!

Das untere Beispiel zeigt, was Ihr nun für den Oktober umgesetzt habt: Die UNBARE Zahlung wird nun als "Warenverkauf" auf das Kassenkonto (1600) gebucht. Und dann generiert Ihr eine zweite Buchung auf das Transferkonto 1460 und dem (richtigerweise) EC-Karten-Konto (1461).

Das passt aus unserer Sicht nun aber gar nicht mehr:

1. Das Kassenkonto sollte ausschließlich BARE Positionen aufweisen und keine Kartenzahlungen
2. Diese zwei Buchungen sollten sich wenigstens ein Konto ausgleichen, so dass unterm Strich nur zwei Konten angesprochen sind. Ihr sprecht nun aber VIER Konten unabhängig voneinander an.

Warum macht Ihr das so und vor allem was können wir dagegen tun?

LG

 

[patoc]

...und noch eine Frage: Was hat es mit diesem Schalter "Gutschein" auf sich?

 

[ofenheizer]

Hallo patoc,

das "warum" steht je leider in den vorigen Posts beschrieben. Mir gefällt diese Lösung auch nicht.

 

[ofenheizer]

...und noch eine Frage: Was hat es mit diesem Schalter "Gutschein" auf sich?

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.

 

[patoc]

Hallo Ofenheizer,

aber das ist doch völliger Murx!

Ich habe die Posts gerade gelesen. Da ging der Schuss irgendwie nach hinten los. Und vor allem völlig an dem Punkt vorbei, weswegen ich diesen Thread gestartet hatte ;-(

Und ein Kassenkonto dann auch noch auf 1460 (Transitkonto) umzustellen ist ja aller übelst, dann stimmt ja hinten und vorne nicht mehr...

Ich schaue mir den Export mal an und schaue, was ich in Richtung DATEV noch durch Logik retten kann. Aber das ist ja mal ein großer Schritt nach hinten gewesen.

LG