Kassenbuch importiert und festgesetzt, nun Fehler entdeckt - Hilfe :-(

[#1]

Guten Morgen liebe Community,

da ich beim letzten Mal super Hilfe von Euch bekommen habe, frage ich auch bei meinem neuen Problem... ich weiß: Selbst dran Schuld! Ist halt doof, wenn alles neu ist und man den falschen Knopf drückt Zu meinem Problem:

Kassensystem ist LS-POS welches eine DATEV-Schnittstelle besitzt, genauer gesagt, man kann das Kassenbuch für die DATEV formatiert exportieren und es auch brav im UO einspielen. Leider habe ich im Januar eine Abweichung von fast 80 Cent und begab mich auf die Fehlersuche. Wir haben Artikel, die  nach kg verkauft werden und wenn nun ein Artikel als Beispiel 3,578€ kostet rundet die Kasse auf 3,58€, rechnet auch mit 3,58€ im Kassenbuch - auch wenn sie nur 3,57€ anzeigt, da sie dort nicht rundet, sondern einfach abschneidet. Ebenso schneidet sie beim Export die 3. Stelle nach dem Komma einfach ab und rundet nicht gescheit, wie man es ja vermuten sollte. Den Support habe ich gestern direkt mal informiert, da ich es schon sehr merkwürdig finde, vor allem da die Kasse als "GDPdU und GoBS - Konform" verkauft wird.

Ich dachte mir dann, ich kann ja die Rundungsfehler per Hand korrigieren (meine Warenwirtschaft zeigt 4 Stellen hinterm Komma an und geht mit der Kasse konform). Dummerweise war es spät, ich war müde, wollte ins Bett und als mich UO fragte, ob ich die Kasse festschreiben möchte habe ich glatt mit Ja geantwortet Ich wollte sie löschen und neu anlegen, geht aber nicht mehr.

Gibt es irgendein Trick, dass ich sie doch noch mal löschen oder resetten kann? Bei der von mir angelegten Kasse "PayPal" geht es auch nach der Festsetzung noch... ansonsten frage ich mich, ob es besser ist die Fehler nun im ReWe zu korrigieren für den Januar und ab Februar dann direkt im UO Kassenbuch und die Kasse mit dort eben mit der Differenz bis zum Jahresende laufen lasse (während im ReWe keine Differenz zum Kassenbuch der Kasse herrscht) - oder ob ich dieses Jahr die Kasse nun auf ein anderes Konto als die 1000 buchen soll und eben neu anfange...

Ich frage das einfach mal hier in die Runde, da meine Steuerfee aufgrund der Osterferien in Urlaub ist und ich mein Quartal in 6 Tagen fertig haben sollte. Und nein, ich lag nicht auf der faulen Haut, die Einrichtung und Fehlerbehebung des ganzen Systems hat mich 9 Wochen und viele Hotline-Anrufe gekostet, deswegen bin ich dieses Mal leider kurz vor Schluss erst dran

Viele Grüße,
Caty

[#2]

Hallo,

nur zur technischen Seite: Die Löschung der Kasse ist hier im Dokument 1071492 beschrieben. Es muss aber mindestens eine Kasse "übrig bleiben" (der Grund erschließt sich mir allerdings nicht).

Falls die Paypal-Kasse später (als 2. Kasse) angelegt wurde, kann das der Grund für die problemlose Löschung in dem Fall sein.

Im Zweifel würde ich eine "Dummy-Kasse" anlegen, um die andere Kasse löschen zu können.

Mit freundlichen Grüßen

Marco Hüwe

[#3]

Beachten Sie aber den vorletzten Satz in dem von Herrn Hüwe verlinkten Dokument:

Grundsätzlich ist das Löschen einer Kasse mit Kassenbuchprüfung nur möglich, wenn im aktuellen Wirtschaftsjahr noch kein Belegsatz festgeschrieben ist.

Daran könnte es im vorliegenden Fall ggf. scheitern.

Wenn ich es richtig verstehe, ist maßgebend Ihre Kasse aus Ihrem System LS-Pos.

Wenn das Kassenbuch in UO nicht das eigentlich für die Buchführung maßgebende Kassenbuch ist (dann dürfte die Übernahme auch nicht nur monatlich erfolgen, sondern müsste täglich durchgeführt werden), würde ich in der Kasse in UO die Differenz durch eine manuelle Buchung am Ende des Monats nachträglich anpassen.

In Rechnungswesen können Sie dann die fehlerhaften Buchungssätze direkt korrigieren und die Buchung mit der Differenz löschen. Dann sollte wieder alles mit Ihrer LS-POS-Kasse übereinstimmen.

Nebenfrage dazu: Warum lesen Sie diese Daten erst in Unternehmen Online ein und nicht gleich im Rechnungswesenprogramm?

Viele Grüße

Uwe Lutz

[#4]

Hallo und vielen Dank für die Antworten

Ja, die Kasse ist wohl durch die Festsetzung nicht mehr löschbar... obwohl ich interessanterweise die 2. Kasse "PayPal" auch nach der Festsetzung noch löschen könnte - liegt aber evtl daran, dass es keine mit Minusprüfung ist? Wäre zumindest der einzige Unterschied zwischen Beiden.

Und ja, mein Kassensystem erstellt automatisch das komplette Kassenbuch, mit Einnahmen und Ausgaben in dem Moment, wo wir mit der Kasse arbeiten.

Ich habe die Daten ins UO Online importiert, da mir das so erklärt worden ist - wenn ich das auch direkt kann, wäre es für mich genauso super! Ist das dann über ReWe - Bestand - Importieren - ASCII-Daten?

Was ich mich noch frage... ich habe vorher immer nur die ganzen Tage für die Kasse gebucht, also Tageseinnahmen 7%, Tageseinnahmen 19%, Differenz, Entnahme/Einlagen.

Ich finde das mit dem Import des kompletten Kassenbuch sehr unübersichtlich, da dort ja jeder Bon einzeln gebucht wird...

Ist es möglich eine eigene ASCII-Vorlage zu erstellen und die Buchungen tageweise zu importieren? Meine Warenwirtschaft kann das schön exportieren, da die Kasse sich mit dieser die Datenbank teilt.

Viele Grüße

[#5]

Das Erstellen von 2 Kassenbüchern (fremd/UO) kann ich nicht nachvollziehen und halte dies auch für problematisch für die Ordnungsmäßigkeit der Buchführung.  Im schlimmsten Fall könnte das Finanzamt auf die Idee kommen auch die “doppelten“ Betriebseinnahmen zu versteuern (Stichwort schwarze Kasse). Warum sollten Sie das so machen und wer hat Ihnen zu dieser Vorgehensweise geraten? Welche Unterstützung haben Sie zur Einrichtung und den Umgang mit UO erhalten? Nur der vorher beschriebene Weg, die Daten direkt in das Rewe einzuspielen (siehe Herr Lutz) ist m.E. richtig.

Wenn jeder „Bon“ einzeln importiert wird, wird eben nicht das Kassenbuch importiert sondern Einzelbuchungen/Einzelaufzeichnungen. Hier ist die Frage ob ihre Fremdsoftware zwischen diesen beiden Dingen beim Export unterscheiden kann. Aus meiner Sicht wäre nur das zusammenfassende Kassenbuch zielführend, denn die Einzelaufzeichnungen befinden sich ja schon in Ihrer Fremdsoftware.

Wie kann eine Kasse den Preis runden? Wenn der Kunde 3,57 bezahlt (tatsächlicher Vorgang) können nicht 3,58 ausgewiesen werden?! Da eine Zahlung mit 3 Nachkommastellen beim Bargeld nicht möglich ist, kann ich dieses Programmverhalten auch nicht nachvollziehen. Stellen Sie Ihr Programm auf den Prüfstand und treten Sie ggf. dem Hersteller auf die Füße.

[#6]

Hallo Herr Dostal,

vielen Dank für diese Antwort! Das macht mir nun einiges wesentlich klarer! An dieser Stelle muss ich sagen, dass es tatsächlich von meiner Steuerfee kam, dass meine Kasse im besten Fall eine Schnittstelle zu DATEV hat - wobei, ich mir nun im Nachhinein ehrlich nicht sicher bin, ob es nur "DATEV" hieß oder UO. Mag sein, dass ich es dann aufgrund des Wort Datev missverstanden habe - ich dachte aber auch bis gestern, dass ich ALLE Daten über das UO einspielen muss.

Die meiste Unterstützung für das UO habe ich über die Hotline erhalten, da es einige Probleme gab, die die Steuerfee nicht kannte oder nicht lösen konnte.

Dem Kassenhersteller bin ich schon auf die Füße getreten und habe den Vorgang zu den Fehlern genau erklärt... leider bisher keine Antwort erhalten. Wie gesagt, wenn wir einen Artikel nach kg-Preis verkaufen wird anscheinend auf 3 oder mehr Stellen hinter dem Komma ausgerechnet und beim Verkaufsvorgang auf- oder abgerundet. Also bei 3,576€ zahlt der Kunde 3,58€, aber das Kassenbuch sagt im Nachhinein 3,57€, rechnet aber mit 3,58€ - die Warenwirtschaft gibt dann zum Vorgang in der Einzelzeile 3,576€ aus, rechnet aber ebenso mit 3,58€ und zeigt genau diese auch als Gesamtsumme an.

Ich bin ehrlich entsetzt über sowas und wirklich gespannt auf die Antwort des Supportes des Kassensystems...

Und nein, die Software kann nicht zwischen irgendwas unterscheiden. Dort gibt es zum Export nur eine Möglichkeit und dort wird nicht der Z-Bon, sowie die Ein- und Auslagen aufgelistet (wie ich es ja erwartet hatte), sondern richtig, jede einzelne Buchung. Also auch Bon 235 mit 7% und Bon 235 mit 19% als je zwei Buchungen.

Ich werde nun die Kasse im UO mit einer Korrektur auf 0 setzen und es dokumentieren als fälschliche Buchung. Da dort zwar die gleichen Bonnummern und überwiegend die meisten Umsätze identisch mit dem Kassenbuch der Kasse oder zu 100% mit der Warenwirtschaft übereinstimmen sollte es zwar erkenntlich sein (bzw. Erklärbar), dass es keine zweite Kasse ist - ABER ich habe natürlich keine Lust auf solch "lustige Geschichten", falls mal eine Prüfung ansteht.

Habe gestern bereits angefangen die Daten der Kasse direkt aus der Warenwirtschaft zu exportieren, dann stimmen die Summen überein und ich kann es tägliche Zusammenfassungen buchen. So wie ich es auch die letzten Jahre getan habe und es im Einklang mit dem Z-Bon steht...

[#7]

Was ist denn eigentlich eine "Steuerfee"?

[#8]

Das weibliche Gegenstück zum "Steuerfuzzi".

(Sorry, der musste sein.)

[#9]

Thomas Kahl hat es gut erkannt