GdPDU-Schnittstelle, welche Daten sind anzuliefern

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

[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)

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

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