GdPDU-Schnittstelle, welche Daten sind anzuliefern

[hanvas]

Zitat von 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.

Ob es sich wirklich um 3 einzelne Bier handelt (3 verschiedene Gäste, jeweils ein Bier, 3 Transaktionen) oder um 3 Bier die auf einmal gekauft werden (ein Gast spendiert sich und seinen Freunden jeweils ein Bier - eine Transaktion) wird oft aber erst zum Zeitpunkt des Bezahlens klar.

Zitat:

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.

Natürlich muss man die 3 Einzelpositionen bei 3 unterschiedlichen Bestellungen nicht zusammenfassen, aber es ist ebenso inkorrekt - auch wenn der Prüfer möglicherweise glücklicher ist - den Einzelvorgang in 3 einzelne Vorgänge aufzusplitten. Beides kann vorkommen und beides kann korrekt sein.

cu Ha-Jö

[jaenicke]

Zitat von hanvas:

oder um 3 Bier die auf einmal gekauft werden (ein Gast spendiert sich und seinen Freunden jeweils ein Bier - eine Transaktion) wird oft aber erst zum Zeitpunkt des Bezahlens klar.

Das sind ja zwei verschiedene Sachen. Das eine sind die Buchungen wie sie eingegeben werden (1 x Bier, 2 x Bier), das andere ist ggf. eine Aufteilung dieser Buchungen auf mehrere Rechnungen. Trotzdem ist bei uns klar welche Eingabe am Ende auf welcher Rechnung gelandet ist.

[arnof]

Das Inhaber geführte Gastronomen bescheissen ist doch bekannt, da ich mich immer geweigert habe eine Steueroptimierung zur Verfügung zu stellen ist unsere Gastroversion für viele Kassenhändler nicht verkaufbar!

Letztes. Jahr musste ein Wiederkäuer von mir die komplette Software und Hardware zurücknehmen, weil bei uns auch alle Trainsbuchungen gespeichert werden (Mafia ....)!

Das wissen auch die Prüfer und kassieren die Branche ab!

Ich hoffe das sich das mit der GoDB erledigt hat, da sich sowas kein Hersteller oder Händler mehr erlauben darf, sonst macht er den Hoeness -)

Österreich hat hier die richtige Lösung, dann ist auch Schuss mit versteckten 2 Kassen!
Das kommt 2020 auch bei uns!

[Captnemo]

Also mit unzulässiger Verdichtung ist folgendes gemeint:

Da es sich, im Fall der Gastronomie, um anonyme Barverkäufe handelt, also der Rechnungsempfänger nicht namentlich erfasst wird, könnte ja ein Gastronom auf die einfache Rechnung kommen, lediglich festzuhalten das er an einem Abend 27 Bier, 6 Cola und 5 Glas Milch verkauft hat, und eben nur diese als ein Vorgang am Schluss in seine Kasse einbucht. In dem Fall würde unzulässig verdichten.
Werden aber auf einem Bon die Getränke und Speisen einer Bestellung zusammengefasst, dann ist diese keine unzulässige Verdichtung, da diese auch einem Gast (oder eben eine Gruppe, von der aber eben nur ein Bezahlvorgang ausgeht) zuzuordnen ist. Ob eine Gruppe dann vorher das Geld sammelt oder ob die Bedienung dieses aufgeteilt kassiert, ist, denke ich mal unerheblich, und auch schwer nachträglich prüfbar.
Bei der ganzen Sache geht es wohl eher um vergleichende Statistik, und weniger um die einzelne Buchung an sich.

Bei Rechnungen ist ja auch üblich und absolut zulässig eine Menge gleicher Artikel in einer Rechnungsposition zusammenzufassen.

Was aber passieren könnte ist, dass ein Prüfer sich mal eine gewisse Zeit in eine Kneipe setzt, und sich die Bestellungen von Gästen notiert. Später dann bei einer Prüfung genau diese Bestellungen raussucht und auf Richtigkeit prüft. Hat es alles schon gegeben. Aber soviel Zeit investieren die sicher nur bei einen gewissen Verdacht.

[bernau]

Ich hole das Thema noch einmal nach vorne.

Habe nun öfters mit dem BMF und Finanzverwaltungen verschiedener Länder gesprochen. Schriftliche Informationen zu bekomme, ist sehr schwer. Aber telefonisch wird etwas mehr erzählt. Alles sehr nette Leute, die sich auch in die Problematik hineinversetzen können. Fakt ist aber, daß es keine Zertifizierung gibt. Ich bin ausserdem darauf aufmerksam gemacht worden, daß es laut Rz179 der GoBD keine Verpflichtung gibt, Zertifizierungen anzuerkennen. Es kann als Entscheidungshilfe verwendet werden. Muss aber nicht.

Siehe http://wiki.gobd-praxis.de/zertifizierung_von_software

[Captnemo]

Eigentlich dachte ich ja, dass ich diesen Kelch an mir vorbei ziehen lassen kann, aber nun hat's mich doch getroffen.
Ein Kunden von mir (der einzige, dem ich mal ein Kassenbuch geschrieben habe) wollte eigentlich auf ein anderes System umsteigen. So zumindest die Aussage im letzten Jahr. Nun hat er sich überlegt, dass die damit verbundenen Unannehmlichkeiten doch zu groß sind, und ich soll das Kassenbuch jetzt GoDB-Fest machen.
Also muss ich mich jetzt doch ernsthaft damit befassen.

1. Das Kassenbuch selbst. Ich erfasse je Buchung Quittungsnummer, Datum/Uhrzeit, Artikel, Menge, Netto, Brutto, MwSt, MwSt-Satz, Stornokennzeichen, den Kassenbenutzer und den dann gültigen Kassenbestand. Reicht das? Oder müssen noch mehr Informationen erfasst werden.
2. Ich habe hier gelesen, dass eine Kassenbuch nicht willkürlich abgeschlossen werden darf. Als im Falle von Täglich, dann immer täglich. Ansonsten müsse das Kassenbuch neu verfasst werden (Den Satz verstehe ich nicht so wirklich). Hier mal das Zitat

Zitat:

9.Die Tagesfolge darf nicht willkürlich sein (bspw. 16.05. —> 09.05. —> 17.05. ...). Sollte die Verarbeitung eines Tages versehentlich unterblieben sein, muss das Kassenbuch neu verfasst werden.

Bei meinem Kunden bucht an der Kasse mehrere Pförtner, der die Kasse dann abschließt, wenn in der Verwaltung jemand da ist, um den Geldbetrag entgegenzunehmen. Der Pförtner ist 24/7 da, die Verwaltung aber nur 5 Tage die Woche und in Ausnahmefälle auch mal gar nicht. Heißt es kommt zu unterschiedlich langen Kassenzeiten. Ist das gültig?
3. Beim Kassenabschluss wird ja der eingenommene Betrag der Kasse entnommen und nur das Wechselgeld verbleibt in der Kasse. Muss diese Kassenentnahme auch als Kassenbuchung im Kassenbuch ganz normal erscheinen z.B (z.B. als "Transfer zur Bank")?
4. Die Übergabe zur Prüfung: Ich habe in verschiedene Programmen, die laut eigenen Angaben GoBD-Konform sein wollen, gesehen, dass sie lediglich eine CSV erzeugen. Ist die XML bzw. DTD zwingend notwendig? Es handelt sich nur um eine Kasse, und es werden auch nicht mehr werden. Und es handelt sich auch immer nur um Einzelbuchung die immer nur eine Position mit festem Betrag haben. Wenn ja, hat irgendwer mal ein paar Dummy-Dateien, die er mal zur Verfügung stellen möchte Damit man sich das mal anschauen kann. Ich kann sowas immer besser verstehen, wenn ich was zum angucken habe.

[jaenicke]

Zitat von Captnemo:

1. Das Kassenbuch selbst. Ich erfasse je Buchung Quittungsnummer, Datum/Uhrzeit, Artikel, Menge, Netto, Brutto, MwSt, MwSt-Satz, Stornokennzeichen, den Kassenbenutzer und den dann gültigen Kassenbestand. Reicht das? Oder müssen noch mehr Informationen erfasst werden.

Wir erfassen noch viel mehr. Was davon erforderlich ist, kann ich aber nicht sagen.
Wichtig ist aber zusätzlich die Unveränderbarkeit der Daten. Sprich du brauchst eine passende Signierung / Verschlüsselung / ...
Und das ist in irgendeiner Form auch vorgeschrieben.

Die einfachste Variante ist eine fortlaufende Durchnummerierung aller Buchungen, was in deinem Fall ja unproblematisch ist. Ob das ohne weitere Maßnahmen reicht, kann ich nicht sagen.

Zitat von Captnemo:

2. Ich habe hier gelesen, dass eine Kassenbuch nicht willkürlich abgeschlossen werden darf. Als im Falle von Täglich, dann immer täglich. Ansonsten müsse das Kassenbuch neu verfasst werden (Den Satz verstehe ich nicht so wirklich).

Gemeint ist nur die Reihenfolge! Sprich du kannst nicht zuerst Montag abschließen, dann Mittwoch und dann den Dienstag hinterher.
Was du denke ich auch erzwungenermaßen brauchst ist eine fortlaufende Abschlagsnummer.

Zitat von Captnemo:

Heißt es kommt zu unterschiedlich langen Kassenzeiten. Ist das gültig?
[...]
Muss diese Kassenentnahme auch als Kassenbuchung im Kassenbuch ganz normal erscheinen z.B (z.B. als "Transfer zur Bank")?

Was spricht denn dagegen beides voneinander zu trennen? Ich meine der Tagesabschluss muss ja nicht heißen, dass das Geld aus der Kasse entnommen wird. Man kann z.B. genauso das Geld am nächsten Tag als Anfangsbestand weiterführen, irgendwann die Entnahme buchen, wenn die Abrechnungen abgegeben werden sollen und den Endbestand entsprechend erfassen.

Zitat von Captnemo:

4. Die Übergabe zur Prüfung: Ich habe in verschiedene Programmen, die laut eigenen Angaben GoBD-Konform sein wollen, gesehen, dass sie lediglich eine CSV erzeugen.

Ein bestimmtes Format ist nicht vorgegeben. Man spart sich bei einer normalen Kassenanwendung nur viel Ärger, wenn man sich an das vorgegebene Format hält. In deinem Fall würde ich denken, dass es auch gut mit einem eigenen Format geht. Du hast ja gar nicht so viele Daten.