Neues Thema starten

Bestellungen in der Gastronomie - widersprüchliche Anleitungen?

Hallo zusammen,


danke für die Aufnahme in diesem Forum.


Nach dem Lesen der offiziellen Dokumente und der Hinweise hier stellt sich mir die Frage, was denn nun das korrekte Vorgehen bei Bestellungen und dem abschließenden Zahlen der Gesamtrechnung?


Hier bei den "Lösungen" steht unter https://support.gastro-mis.de/support/solutions/articles/36000170275-bestellung-oder-nicht-wie-sichert-man-die-vorgänge-ab , dass jede Bestellung eine eigene Transaktion mit Start/FInish ist und erst beim späteren Bezahlen sozusagen losgelöst davon eine eigene Beleg-Transaktion mit Start/Finish gemacht wird.


Im offiziellen Dokument zur Schnittstelle auf Seite 111, sieht es optisch so aus, dass man bei der ersten Bestellung die Transaktion "Kassenbeleg" startet, dann über den Verweilzeitraum des Gastes mehrere Transaktionen für die Bestellungen tätigt und am Schluss die ganz zu Beginn gestartete Beleg-Transaktion mit Finish schließt.


Welches davon ist korrekt oder ist das am Ende egal?


Und habe ich es richtig verstanden, dass man die einzelnen "Bestell"-Transaktionen im DSFinV-K-Export gar nicht auflisten muss, weil's ja dazu keine Belege gibt? Die Bestellpositionen sind ja nachher Positionen im Rechnungsbeleg und damit in der Bonpos-Datei enthalten. Allerdings fehlt dann eine direkte Verknüpfung der einzelnen Bestellungen zu den Transaktionen in der TSE....


Man bekommt einen Knoten ins Gehirn :-/


Danke & Liebe Grüße

Alexander


Hallo Herr Schmitt,

m.E. sind beide Lösungen korrekt.

Im DSFinV-K 2.2 Anhang H sind verschiedene Wege, u.a. mit und ohne update_transaction beschrieben.

Ich persönlich habe den Weg mit einer ersten Transaktion und der späteren (Rechnungs-)Transaktion gewählt, bei der auf dem Beleg zusätzlich die Nummer und Startzeit der ersten Transaktion steht.

Für eine genaue Prüfung ist ohnehin in keinem Fall die TSE oder irgendein Export daraus ausreichend. Im Normalfall enthält die TSE ja nur Belegsummen, überhaupt keine Positionen (Scannerkasse oder Warenkorb). Der Tar-Export der TSE erlaubt lediglich eine überschlägige Prüfung der Summen, erst der DSFinV-K-Export (so wie früher GDPdU) ermöglicht eine Analyse z.B. der Umsatzsteuer. Allerdings deckt der TSE-Export gewisse Anomalien (Zeitsprünge, übermäßige Trainings oder Stornos) auf, die dann ggf. zu einer tieferen Prüfung führen könnten.

Viele Grüße

U. Kleinert


Hallo Herr Kleinert,


vielen Dank für die Antwort, das bringt mir mehr Klarheit.


Auf meine letzte Frage habe ich aber noch keine Antwort gefunden. Muss nicht auch abseits der Uhrzeit und TA-Nummer der ersten Bestellung ein Zusammenhang zwischen den (vielen) auf TSE signierten "Bestellung"-Transaktionen eines Geschäftsvorfalls ein Zusammenhang hergestellt werden?


In der DSFinV-K Kapitel 2.7.2 steht:

"Der Start-Zeitpunkt der ersten Transaktion „Bestellung“ muss zusätzlich auf dem Bon abgedruckt werden. Darüber hinaus muss gewährleistet sein, dass der inhaltliche Zusammenhang über das Feld ABRECHNUNGSKREIS in der Datei Bonkopf_AbrKreis (vgl. 3.1.2.2) in den DSFinV-K-Daten hergestellt werden kann, um die Entstehung und Abwicklung der einzelnen Bestell- und Abrechnungs-Vorgänge nachvollziehen zu können."


Würde sich daraus nicht ergeben, dass der ABRECHNUNGSKREIS auch irgendwo in den durch die TSE abgesicherten "Bestellung"-Transaktionen abgelegt werden müsste? Nur dann wären doch die TSE-Transaktionen der 2., 3., 4., .... Bestellung auch zweifelsfrei zuzuordnen und nachzuvollziehen.


Viele Grüße

Alexander Schmitt

Hallo Herr Schmitt,

Ihre Ausführungen klingen logisch, aber wir haben es hier ja mit einem EU- bzw. deutschen Bürokratiemonster zu tun. Da ist Logik fehl am Platz. Ich habe diese Denkweise bereits direkt abgelegt, als ich angefangen habe, mich mit der TSE zu beschäftigen.

Wichtig ist zu verstehen, daß die TSE allein keinerlei Aufschluß gibt, welche Waren wie verkauft wurden, denn bei einer Scannerkasse z.B. sieht die TSE niemals einen Artikel. Nur der TSE-Tar-Export i.V. mit dem DSFinV-K-Export hat einen Aussagewert. Im DSFinV-K-Export dürfen keine Belege auftauchen, die nicht an die TSE gegangen sind, ebenso dürfen keine Transaktionsnummern fehlen. Die zusätzliche Start-Transaktion wurde m.E. nur geschaffen, damit man keine Vorgänge, die man "ohne TSE buchen wollte", später noch heilen kann (wenn man merkt, daß der Käufer ein Prüfer ist oder daß der Kunde doch einen Bon möchte).

Übrigens: Solange die TSE-SN noch nicht beim FA angemeldet werden kann, hat das Ganze ohnehin keinen Sinn, denn hier könnte man ja zwei TSE haben, eine für's FA, eine nebenher. So wären immer alle Bons okay, niemand würde den Schwindel merken.

Viele Grüße

U. Kleinert

Guten Morgen Herr Kleinert,


ganz herzlichen Dank für Ihre ausführlichen Erklärungen, das hilft mir sehr weiter.

Als Datenbankentwickler sind Logik und Konsistenz natürlich bei mir oberstes Gebot und ich habe beim Lesen der Verordnungen schon häufiger gedacht, "das kann man auch anders machen"...

Hier wird sowieso eine riesige Kanone aufgebaut, mit der auf ein paar schwarze Schafe geschossen wird, und wie es immer ist, alle haben den Aufwand und die Kosten, aber wer wirklich mit krimineller Energie betrügen will, findet auch weiterhin Wege dazu :-(

Ich werde also alles so implementieren, wie es in der Verordnung steht und der Prüfer kann sich bei der Nachschau dann selber fragen, ob das alles so überhaupt logisch ist.


Viele Grüße,

Alexander Schmitt

Hallo Herr Schmitt,

wie gesagt, mit Logik hat es unsere Regierung ja schon seit geraumer Zeit nicht mehr so...

Anosnten hätte man ja z.B. "logischerweise" vorher über die Anmeldung der TSE und der Kassen beim FA nachgedacht...

Wie ist z.B. die "räumliche Nähe" der TSE zur Kasse definiert? Was bedeutet, "wenn das Kassenmodul auch Bargeldzahlungen abwickelt" (was genau ist ein Modul)?

Diese ganze Verordnung ist von hinten bis vorn eine Katastrophe, die natürlich im Zweifelsfall immer zu Ungunsten des Steuerzahlers ausgelegt wird.

Ich wünsche Ihnen trotzdem viel Erfolg bei der Umsetzung.

Viele Grüße

U. Kleinert


Anmelden oder Registrieren um einen Kommentar zu veröffentlichen