GdPDU-Schnittstelle, welche Daten sind anzuliefern

[Lemmy]

Zitat von jaenicke:

Zitat von Lemmy:

dann besserst Du nach

Du hast dann aber nicht mehr die Unveränderbarkeit der Daten vollumfänglich gewährleistet, wenn die GdPDU-Daten nacherzeugt werden.

die Prüfdaten fürs FA werden erzeugt wenn sie gebraucht werden. Weshalb sollte hier die (inhaltliche) Unveränderbarkeit der Daten nicht gewährleistet sein?

[Neumann]

Für uns gab es, nachdem etliche Kunden in den letzten Jahren ohne wesentliche Probleme durch die Steuerprüfung gekommen sind, jetzt einen Fall (Gastronomiebetrieb) der fast schiefgegangen wäre.

Der Prüfer monierte folgendes:

Wir würden Daten unzulässig verdichten durch z.B. wie in folgendem Beispiel : Ein Gast bestellt nacheinander über den Abend 3 mal ein gleiches Getränk, wenn dann später die Rechnung gezogen wird rechnet das Programm diese 3 zusammen und schreibt auf den Bon dann eben 3 Pils zu 2€ = 6 E.
Genauso wird es dann gespeichert.

Danach, wenn der Bon gedruckt ist werden diese Daten nie wieder verändert.

Ein weiteres Problem für diesen Prüfer war, das die einzelnen Buchungen (nicht die Rechnungen / Bons, da war alles ok) keine lückenlose fortlaufende Nummerierung haben.

Unser Kunde hatte noch eine ältere Version von dem Kassenprogramm; aber die "Verdichtung" ist jetzt immer noch drin und ich werde da wohl was tun müssen.

[mm1256]

Zitat von Neumann:

Der Prüfer monierte folgendes:

Wir würden Daten unzulässig verdichten durch z.B. wie in folgendem Beispiel : Ein Gast bestellt nacheinander über den Abend 3 mal ein gleiches Getränk, wenn dann später die Rechnung gezogen wird rechnet das Programm diese 3 zusammen und schreibt auf den Bon dann eben 3 Pils zu 2€ = 6 E.
Genauso wird es dann gespeichert.

Man hat als Steuerzahler nicht nur Pflichten, sondern auch Rechte. Wer sich als Steuerzahler solche Schikanen vom Prüfer gefallen lässt, dem ist wirklich nicht mehr zu helfen. Meiner Erfahrung nach werden solche "Repressalien" von Prüfern angewandt um ein Indiz zu erhalten, ob beim Steuerzahler alles sauber gebucht wurde. In diesem Fall ist das Thema die Schwarzgastronomie. Denn, wer wirklich eine weiße Weste hat, der schickt den Prüfer in diesem Fall dahin wo er hin gehört, in die Wüste.

[Neumann]

Das wäre schön wenn man einen Prüfer in die Wüste schicken könnte.

Der Kunde kann nur vor Gericht gehen, mit ungewissem Ausgang und ev. weiteren Kosten.

[jaenicke]

Ich bin ja kein Anwalt, aber wir haben solche Fragen ja auch schon zur Genüge durch.

Zitat von Neumann:

Wir würden Daten unzulässig verdichten durch z.B. wie in folgendem Beispiel : Ein Gast bestellt nacheinander über den Abend 3 mal ein gleiches Getränk, wenn dann später die Rechnung gezogen wird rechnet das Programm diese 3 zusammen und schreibt auf den Bon dann eben 3 Pils zu 2€ = 6 E.
Genauso wird es dann gespeichert.

Das ist korrekt, das ist nicht zulässig. Jede Buchung muss so gespeichert werden wie sie eingegeben wurde. Eine Verdichtung der Daten ist nicht zulässig. Weder direkt bei der Buchung (nur Anzahl hochzählen, ...) noch beim Abschlag (alle Buchungen einzelner Artikel zusammenrechnen, ...).

Sprich dagegen besteht meiner Meinung nach vor Gericht wenig Aussicht auf Erfolg, wenn es deshalb Probleme gibt. Das sollte natürlich trotzdem ein Anwalt anschauen, da es ja vermutlich um einiges Geld geht.
Denn durch die unzulässige Speicherung werden die Daten ja nicht gleich gänzlich ungültig.

Zitat von Neumann:

Ein weiteres Problem für diesen Prüfer war, das die einzelnen Buchungen (nicht die Rechnungen / Bons, da war alles ok) keine lückenlose fortlaufende Nummerierung haben.

Das ist nicht vorgeschrieben. Nicht einmal für die Rechnungen.

Auch Lücken in Rechnungsnummern sind theoretisch kein Problem. Praktisch ist es für viele Prüfer dennoch ein Ansatzpunkt, wenn es eine fortlaufende Nummerierung gibt und dann Lücken vorhanden sind. Eigentlich ist der Schluss, dass deshalb etwas nicht korrekt ist, nicht zulässig.

[mm1256]

Zitat von jaenicke:

Ich bin ja kein Anwalt, aber wir haben solche Fragen ja auch schon zur Genüge durch.

Zitat von Neumann:

Wir würden Daten unzulässig verdichten durch z.B. wie in folgendem Beispiel : Ein Gast bestellt nacheinander über den Abend 3 mal ein gleiches Getränk, wenn dann später die Rechnung gezogen wird rechnet das Programm diese 3 zusammen und schreibt auf den Bon dann eben 3 Pils zu 2€ = 6 E.
Genauso wird es dann gespeichert.

Das ist korrekt, das ist nicht zulässig. Jede Buchung muss so gespeichert werden wie sie eingegeben wurde. Eine Verdichtung der Daten ist nicht zulässig. Weder direkt bei der Buchung (nur Anzahl hochzählen, ...) noch beim Abschlag (alle Buchungen einzelner Artikel zusammenrechnen, ...).

Könntest du mir bitteschön mal die entsprechende Stelle im Gesetzestext bzw. einen Link darauf posten? Der Grund: Ich vermute, dass ihr da was falsch interpretiert. Wenn der Gast ein Getränk ordert und danach (am gleichen Tag und am selben Tisch) ein weiteres Getränk, dann sind dies zwar Bestandteile einer Buchung (des Bon's, den der Gast erhält) aber für sich gesehen keine eigenen Buchungssätze.

[jaenicke]

Zitat von mm1256:

Könntest du mir bitteschön mal die entsprechende Stelle im Gesetzestext bzw. einen Link darauf posten? Der Grund: Ich vermute, dass ihr da was falsch interpretiert. Wenn der Gast ein Getränk ordert und danach (am gleichen Tag und am selben Tisch) ein weiteres Getränk, dann sind dies zwar Bestandteile einer Buchung (des Bon's, den der Gast erhält) aber für sich gesehen keine eigenen Buchungssätze.

Ich finde keine Stelle, an der es eine Ausnahme von der Einzelaufzeichnungspflicht innerhalb einzelner Rechnungen gibt. Es steht überall nur, dass die Verdichtung generell nicht erlaubt ist. Warum sollte es einen Unterschied machen, ob ich innerhalb einer Rechnung verdichte, wenn dies nicht explizit anders geregelt ist?

Wir zeichnen jedenfalls ohnehin jede Buchung einzeln auf und ändern daran danach nichts fiskalisch Relevantes mehr, schon aus Gründen der Nachvollziehbarkeit, insofern kann es uns egal sein, ob der andere Weg theoretisch auch ginge.

[hanvas]

Zitat:

Es steht überall nur, dass die Verdichtung generell nicht erlaubt ist. Warum sollte es einen Unterschied machen, ob ich innerhalb einer Rechnung verdichte, wenn dies nicht explizit anders geregelt ist?

Weil Du (gerade aber nicht nur in der Gastronomie) oft vor dem Bezahlen gar nicht weist ob überhaupt eine Verdichtung vorliegt.

Jeder ist wohl schon zusammen mit anderen, in ein Lokal gegangen und wurde erst beim Bezahlen gefragt : "jeder für sich oder alle zusammen" Das heißt das bis zu diesem Zeitpunkt sowohl 3 Bier an einen Rechnungsempfänger gehen können (und wohlmöglich eine Verdichtung vorliegt) oder aber auch 3 * 1 Bier an jeweils eine Person gegangen ist - und dementsprechend korrekterweise 3 Belege zu erstellen sind.

Und was ist wenn Gäste habe die Ihren "Deckel" nicht sofort begleichen, ist das eine Verdichtung oder habe ich nur unterschiedliche Leistungs und Rechnungszeitpunkte (wobei dann die Zusammenfassung ja wieder erlaubt ist).

Die gleichen Fragen stellt sich - zwar nicht aus Sicht des Programierers aber zumindest rechtlich - wenn die Bedienung im wahrsten Sinne des Wortes einen Deckel schreibt und erst beim Bezahlvorgang boniert - ist das eine Verdichtung oder ein vom Rechnungszeitpunkt abweichender Leistungszeitpunkt - und wenn die Bedienung das darf, warum darf man das mit einer Kasse nicht.

cu Ha-Jö

[Neumann]

Nächste Möglichkeit ist noch, dass ich auf die Rechnung schreibe:

3 Pils 6 € und dies in Tabelle A speichere,

und in Tabelle B speichere ich:

1 Pils 19:30
1 Pils 20:00
1 Pils 20:15
Dann kann ich nachweisen heute 157 Artikel gebucht, die Summe der Anzahl müsste ja in beiden gleich sein. A könnte ich noch mit B verknüpfen.

Über den Fall, das die fröhliche Runde 10 Pils bestellt und der Kellner 10*Pils einbucht und es nachher drei Leute bezahlen (3,3,4) muss ich noch nachdenken.

[jaenicke]

Zitat von Lemmy:

die Prüfdaten fürs FA werden erzeugt wenn sie gebraucht werden. Weshalb sollte hier die (inhaltliche) Unveränderbarkeit der Daten nicht gewährleistet sein?

Die Unveränderlichkeit gilt bei uns auch für die täglich beim Tagesabschluss erzeugten GdPDU Exporte. Mehr möchte ich da aber nicht ins Detail gehen.