GdPDU-Schnittstelle, welche Daten sind anzuliefern

**arnof**

@Captnemo: 7500,- EUR +MwSt

ich habe nun alles was mit Kasse zu tun hat um 100,- EUR vom Preis erhöht für die Finanzierung.

@Neumann:@jaenicke:3 Pils zu 2€ = 6 E.

Verdichtung ist unzulässig, das ist richtig, es ist aber erst nach den BON unzulässig, vor dem BON kann man verdichten. Es geht um die unveränderliche Datenvorhaltung zwischen BON und späterer GoBD Ausgabe, das muss übereinstimmen.

@all: ich war erst ende August auf einer Tagung in der Hauptstadt. Hier waren auch die obersten Steuerprüfer aus NRW (Bundesweit wohl für Kassen die Ansprechpartner für andere Bundesländer).

Fazit: Es gibt keine Vorgaben, Unveränderlichkeit von Daten heist nicht unveränderbar (es muss halt dokumentiert sein

was geändert wurde); Änderung für 2020 keiner weiss was, jeder Wünscht sich was .....

**Neumann**

Hallo Arnulf,

der Meinung war ich ja auch. Sobald der Bon gedruckt oder gespeichert ist, nichts mehr an den Daten ändern. Der besagte Prüfer sieht das allerdings anders. Keine Eingabe darf korrigiert oder verändert werden, auch schon wenn nur eine Bestellung eingegeben wird.
Ich tendiere jetzt dazu, alles parallel auf einen Secumem-Stick zu schreiben, z.B. als CSV-Datei. Die kann dann mit den verarbeiteten Daten verglichen werden.

Der Prüfer hat sich auch in tagelanger Arbeit durch unsere Datenbank gekämpft und vieles mokiert, wie schon angesprochen die nicht lückenlosen Buchnummern oder die doppelte Speicherung von Daten in Tabellen und Views, wobei die Daten in den Views "Überhaupt nicht sortiert waren", sein Kommentar dazu.

Übrigens wurden alle Gastronomiebetriebe die von diesem Prüfer dort geprüft wurden zu Nachzahlungen verdonnert, egal von welchem Hersteller das Kassensystem war, alle wurden als manipulierbar beschuldigt.

**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ö

**arnof**

Zitat von Neumann:

Hallo Arnulf,

der Meinung war ich ja auch. Sobald der Bon gedruckt oder gespeichert ist, nichts mehr an den Daten ändern. Der besagte Prüfer sieht das allerdings anders. Keine Eingabe darf korrigiert oder verändert werden, auch schon wenn nur eine Bestellung eingegeben wird.
Ich tendiere jetzt dazu, alles parallel auf einen Secumem-Stick zu schreiben, z.B. als CSV-Datei. Die kann dann mit den verarbeiteten Daten verglichen werden.

Der Prüfer hat sich auch in tagelanger Arbeit durch unsere Datenbank gekämpft und vieles mokiert, wie schon angesprochen die nicht lückenlosen Buchnummern oder die doppelte Speicherung von Daten in Tabellen und Views, wobei die Daten in den Views "Überhaupt nicht sortiert waren", sein Kommentar dazu.

Übrigens wurden alle Gastronomiebetriebe die von diesem Prüfer dort geprüft wurden zu Nachzahlungen verdonnert, egal von welchem Hersteller das Kassensystem war, alle wurden als manipulierbar beschuldigt.

Prüfer sind auch oft Ahnungslos,der hat halt gelesen "Verdichtung ist verboten" und sonst ....

Hier muss man sich halt rumärgern.

Ich hatte auch die GoDB via AutoInc Felder verknüpft ausgegeben und der gute Prüfer hat das nicht gerafft und kam mit einer Lückenprüfung, das dort nichts fehlen darf ... Es darf aber keine Bonnummer fehlen, hier musste ich den Kunden auch mehrmals schriftlich zur Seite stehen!
Es ging halt bis zu seinem Vorgesetzten, dann war alles OK!

Man lernt immer dazu, ich habe deshalb beim GOBD Export die Autoinc Felder raus genommen und via Nummern verknüpft, damit ich mir diese Diskussionen ersparen kann.

**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.

**bernau**

Zitat von arnof:

Prüfer sind auch oft Ahnungslos,der hat halt gelesen "Verdichtung ist verboten" und sonst ....

Hier muss man sich halt rumärgern.

Leider. Und man hat nicht wirklich eine Chance als Programmierer etwas dagegen zu machen. Kannst den ja theoretisch nicht verklagen. Er prüft ja nicht dich sondern deinen Kunden. Der Kunde klagt lieber nicht sondern nimmt das kleinste übel. Und du hast das schlechte ansehen.

Laut Prüfer müssen sämtliche Änderungen in den Stammdaten protokolliert werden. Das ist noch verständlich, wenn die Preise der Produkte alle 2-3 Monate geändert werden. Was aber, wenn Goldpreise die sich stündlich ändern, in der Kasse kassiert werden sollen? Soll der Preis tatsächlich Protokolliert werden? Eigentlich ist doch nur der Preis relevant, zu dem ein Produkt verkauft wurde. Erzähl das mal einem Steuerprüfer.

**jaenicke**

Zitat von hanvas:

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

Doch. Der Bediener hat zum Beispiel 3 mal ein einzelnes Pils gebucht. Dann sind das auch erst einmal drei Transaktionen.
Dass man diese als 3 Pils anzeigt, ist klar, aber das heißt doch nicht, dass man dafür die Datensätze zu einem Datensatz verdichten muss.
Und was ist, wenn ich zwei Schnitzel buche, in der Küche drucke und dann eins wieder storniere? Unterschlägt du dann den Storno und speicherst nur das eine Schnitzel verdichtet ab?

Zitat von bernau:

Was aber, wenn Goldpreise die sich stündlich ändern, in der Kasse kassiert werden sollen? Soll der Preis tatsächlich Protokolliert werden?

Wir protokollieren tatsächlich jede einzelne Änderung. Interessieren sollten unbenutzte Zwischenergebnisse allerdings wirklich nicht...

**mm1256**

Hallo,

mittlerweile habe ich ja nichts mehr mit Gastrokasse zu tun, aber früher zu DOS-Zeiten hatte ich mal eine programmiert. Die gibt es zwar heute unter Windows auch noch, aber ich entwickle sie nicht mehr.

Da war es so, und ist es auch heute noch, dass alle aktuellen Buchungen an den Tischen einzeln in einer separaten Datenbank gespeichert wurden. Erst beim Bezahlen wurde verdichtet. Anders bekommt man meiner Meinung nach die Probleme nicht so gut in den Griff. Stichworte Netzwerkfähigkeit, Übersicht offene Tische, Umbuchen einer oder mehrerer Gäste auf einen anderen Tisch, Kellnerwechsel, Schichtwechsel, Stornierungen, Fehlbestellungen, Notizen zu den einzelnen Bestellungen (Kartoffelsalat anstatt Pommes zum Schnitzel, das Steak medium...usw) und allem was sonst nicht zwingend im Journal stehen muss.

Wenn dann beim Bezahlen die einzelnen Positionen verdichtet in das Journal geschrieben werden, dann ist das - um zurück zum Thema zu kommen - meiner Meinung nach steuerrechtlich in Ordnung.

**bernau**

Zitat von jaenicke:

Wir protokollieren tatsächlich jede einzelne Änderung. Interessieren sollten unbenutzte Zwischenergebnisse allerdings wirklich nicht...

Änderungen im Artikelstamm müssen Protokolliert werden, egal ob die Produkte verkauft werden. Es ist egal, ob die Preise alle 5 min. geändert werden oder alle 5 Tage.

Du müsstes den Preis vom Glas "Alt-Bier", welches in Köln nicht getrunken wird, erst zwei drei mal senken, bevor es das erste mal verkauft wird. Die 2-3 Preissenkungen wirst du doch in der Gastrokasse protokollieren. Oder? Wo ist der Unterschied zum Goldpreis, welcher dann nicht protokolliert werden soll? (Ausser dass Gold tatsächlich mehr Wert ist als Alt-Bier)