Kassensicherheitsverordnung

[herbstrot]

Hallo,

je mehr ich mich mit der KassenSichV beschäftige umso verwirrter bin ich.
Die Art und Weise der Transaction bereitet mir Kopfzerbrechen.

Beim Erstellen des Bons wird StartTransaction aufgerufen, so weit so gut.

Nun liest man das nach 45 Sek. UpdateTransaction ausgeführt werden soll. In anderen Quellen heißt es das man das nicht mehr braucht.
Was ist nun richtig und wo steht es verbindlich geschrieben?

Bon wird abgeschlossen, also FinishTransaction aufrufen.

Was ist mit den Vorgängen zwischen Start und Finish? Zubuschen, löschen, Mengen und Preise ändern wirken sich in der Transaktion garnicht aus, da nur Endbeträge geschrieben werden.
Vieleicht kann ja jemand Licht ins Dunkle bringen.

[jaenicke]

Dazu findest du hier entsprechende Informationen:
https://www.bzst.de/DE/Unternehmen/A...finv_node.html
In dem Download liegt eine PDF-Datei, in der sowohl das Exportformat als auch das TSE-Handling und die an die TSE zu sendenden Daten beschrieben sind.

An der Stelle seien noch die Middlewarelösungen wie z.B. Fiskaltrust oder EFSTA erwähnt, die lediglich die Daten brauchen und die TSE selbst ansteuern und als Cloudlösung auch DSFinV-K Exporte usw. erstellen.

[herbstrot]

Moin,

die DSFinV-K ist mir bekannt und ich weiß welche Daten wo zu Exportieren sind.
Das im Export alle relevanten Daten vorhanden sein müssen schon klar. Beantwortet aber nicht die Frage ob UpdateTransaction genutzt werden muss (steht soweit ich weis nicht in der DSFinV-K).

[DeddyH]

Soweit ich es verstanden habe und mir in div. Fachgesprächen auch bestätigt wurde ist UpdateTransaction nur bei länger dauernden Bestellvorgängen von Belang (Gastronomie z.B.). Der Gast kommt in ein Restaurant und bestellt sich ein Wasser. Zusammen mit diesem bekommt er die Speisekarte ausgehändigt. Die Bestellung wird also gestartet und enthält das Wasser als Position. Nun bestellt er sich eine Vorsuppe. Der Kellner nimmt alles mit einer Tablet-App auf. Spätestens 45 Sekunden nach Erfassung in der App muss nun ein Update auf die Transaktion erfolgen mit der Vorsuppe als Position. Das wiederholt sich für jede weitere Teilbestellung. Ist der Gast irgendwann wunschlos glücklich, wird die Bestellung abgeschlossen und mit der Zahlung der Beleg gestartet. Beim Start des Belegs werden keine weiteren Daten angegeben (processData und processType sind leer). Erst beim Abschluss des Belegs sind die Angaben zu den Beträgen je Steuersatz und den einzelnen Zahlarten zu hinterlegen und ein Bon (in gedruckter oder digitaler Form) zu erzeugen. Ich hoffe, ich habe das jetzt korrekt und verständlich wiedergegeben.

[hhcm]

Gastro MIS sagt da was anderes zu.

Siehe --> hier <--

[jaenicke]

Zitat:

Zitat von herbstrot (Beitrag 1455192)

Beantwortet aber nicht die Frage ob UpdateTransaction genutzt werden muss (steht soweit ich weis nicht in der DSFinV-K).

Die PDF in dem Link schon... wie schon geschrieben:

Zitat:

Zitat von jaenicke (Beitrag 1455190)

In dem Download liegt eine PDF-Datei, in der sowohl das Exportformat als auch das TSE-Handling und die an die TSE zu sendenden Daten beschrieben sind.

Zitat:

Zitat von DeddyH (Beitrag 1455196)

Die Bestellung wird also gestartet und enthält das Wasser als Position. Nun bestellt er sich eine Vorsuppe. Der Kellner nimmt alles mit einer Tablet-App auf. Spätestens 45 Sekunden nach Erfassung in der App muss nun ein Update auf die Transaktion erfolgen mit der Vorsuppe als Position. [...]

Das ist überholt. Wenn man die Transaktion direkt startet und offen hält, muss man diese auch in der gleichen TSE abschließen usw., so dass man kein Bonfloating nutzen kann usw., so dass das dann entschärft wurde.

Aber das steht alles in dem oben genannten Link.

[hhcm]

Also zusammenfassend gesagt

Zitat:

Für alle Transaktionstypen gilt, dass processType und processData für die Start-Transaction-Operation immer leer sind. StartTransaction wird unmittelbar mit Beginn eines Vorgangs an der Kasse aufgerufen. Die UpdateTransaction-Operation wird nicht verwendet. Die folgende Beschreibung bezieht sich ausschließlich auf die FinishTransaction-Operation.

Also egal ob man einen Bon Parkt und eine Woche später erst abschliesst, ein Kellner 5x zum gleichen Tisch rennt, alles egal..

Start (Alles leer)
Ende (Prozesstyp und Umsätze angeben)

Fertig?

[herbstrot]

Moin,

also wenn ich das jetzt richtig verstanden habe, dann braucht es kein UpdateTransaction mehr?
Also wäre der Weg beim durchbuchen:

StartTransaction
Positionen buchen...
FinishTransaction

Beim parken des Bons:

StartTransaction
Positionen buchen...
FinishTransaction

Beim erneuten ändern des Bons wiederum:

StartTransaction
Positionen buchen...
FinishTransaction

Bis der Bon bezahlt wird und dann wiederum
StartTransaction
FinishTransaction

[himitsu]

Zitat:

Zitat von herbstrot (Beitrag 1455628)

Bis der Bon bezahlt wird und dann wiederum
StartTransaction
FinishTransaction

Was machst'e eigentlich, wenn du zwischendurch wieder zum Kunden an den Tisch kommst (was Tinken, Vorspeiße, ....? ), den Vorgang fortsetzt (StartTransaction) der Kunde überlegt und dann meint "nee doch nicht" und du wieder gehst (FinishTransaction) ... druckt der dann jetzt schon, weil keine neue Position?

[jaenicke]

Der Vorgang wird ja erst bei einer Änderung an die TSE geschickt. Solange nichts Wertveränderndes passiert, wird auch nichts geschickt.

[hhcm]

Zitat:

Zitat von jaenicke (Beitrag 1455637)

Der Vorgang wird ja erst bei einer Änderung an die TSE geschickt. Solange nichts Wertveränderndes passiert, wird auch nichts geschickt.

Wertverändernd ist doch eigentlich alles. Position hinzubuchen, Menge ändern oder irgendetwas stornieren.
Entweder stelle ich mich zu blöd an, oder das ganze ist sehr Schwammig beschrieben.
Update oder Start+Ende?

Was wird denn jetzt beim "normalen" Kassieren gemacht?

- Erste Position = Transaktion Starten (Das sollte jedem klar sein)
- Weitere Position. (Update ist scheinbar nicht nötig. Was jetzt? (Ist doch schließlich Wertverändernd)
- Zeilenstorno - Siehe oben
- Bezahlen = Transaktion Beenden.

Natürlich muss bei der DSFinV-K auch vieles anderes Exportiert werden - aber wie hilft die TSE dabei?

[ISMIRSCHLECHT]

Mahlzeit,

hehe, ich bin auch mit dieser Sch... beschäftigt.
Bei Vollgastronomie ( stundenlanges am Tisch sitzen und dann Abkassieren) geht das angeblich so:
1. Bestelltransaktion (PTYPE Bestellung-V1 oder so)
Start() - Finish()
2. Bestelltransaktion Start() - Finish()
... und so weiter
13. Bestelltransaktion Sart() Finish()

Kassieren => Start() und gleich danach das Finish() mit den PDATA (Steuercontainer und Zahlungsarten) der abkassierten Artikel.

Aber ich beziehe mich da auf GastrMIS , und habe schon ein paar greue Haare mehr als am Anfang.
ism

[hhcm]

Zitat:

Zitat von ISMIRSCHLECHT (Beitrag 1455847)

Aber ich beziehe mich da auf GastrMIS , und habe schon ein paar greue Haare mehr als am Anfang.
ism

Das hat mit GastroMIS nichts zu tun. Das muss bei jeder anderen TSE auch gemacht werden. (Wenn´s denn richtig ist)

[Neumann]

Ja so mache ich das auch. Auf dem Bon muss dann Datum/Zeit vom Start der ersten Transaktion und Stop der letzten.

Ich speichere die Zeitwerte einfach in jedem Datensatz der Buchungstabelle mit, dann ist das einfach.


Frage an die Kollegen: Wer hat schon alles fertig?

Die TSE-Geschichte habe ich bis auf den Export, die Json für den Z-Bericht im wesentlichen auch fertig.

CSV muss ich wohl noch machen.

[herbstrot]

Moin,

laut DSFinV-K Seite 108 ist zu beachten, dass bei dem PType Bestellung-V1 als PData Menge, Bezeichnung, Preis bei FinishTransaction übergeben werden muss. Also im Grunde sämtliche Positionen des Bons. Da kann unter Umständen ein ziemlich langes PData bei rauskommen.

Fertig, nein noch nicht. Dazu sind einfach zuviele FRagen ungeklärt.

[Rollo62]

Bin jetzt nicht zu tief im Thema, aber habt ihr euch schonmal damit beschäftigt ?

Variante 1:

Zitat:

1. Bestelltransaktion (PTYPE Bestellung-V1 oder so)
Start() - Finish()
2. Bestelltransaktion
Start() - Finish()
... und so weiter
<=== STROMAUSFALL
13. Bestelltransaktion
Start() Finish()

Variante 2:

Zitat:

Start()
1. Bestelltransaktion (PTYPE Bestellung-V1 oder so)
2. Bestelltransaktion
... und so weiter
<=== STROMAUSFALL
13. Bestelltransaktion
Finish()

Also Variante 1 wäre vorteilhafter, aber keine der Beiden kann jetzt korrekt buchen,
oder sehe ich das falsch.
Entstehen hier wieder Milliardenschwere Lücken im Bon-System, die wir nur USV-Pflicht verhindern können (kostet nur Billiarden) :stupid:

[DeddyH]

Man kann sich eine Liste der noch offenen Transaktionsnummern zurückgeben lassen und "verhunzte" Transaktionen dann immer noch abschließen oder stornieren oder.... Das ist aber natürlich auch mit einigem Aufwand verbunden, da man ja irgendwie den Soll- und Ist-Zustand vergleichen muss. Ich bin immer noch der Meinung, dass man die österreichische Lösung hätte übernehmen sollen, aber mich fragt ja keiner.

[Rollo62]

Ja, und die Restaurants müssen sich eine Gästeliste geben lassen (DSGVO),
dann die Bestellungen separat auf einem Bierdeckel verwalten (BierDVO),
und dann wenn alle Gäste bezahlt haben und gegangen sind, nachträglich die Zettel per Post zuschicken (KasVO). :-D

@DeddyH
Ich habe dich gefragt, ich dachte schon ich wäre der Einzige dem dieser Stuss auffällt ...
Demnächst müssen Einzelhandelsverkäufer (innen)(GenderVO) ein abgeschlossenes Studium der Rechtswissenschaften nachweisen.

Es wird Zeit dies mal in ein neues Gesetz zu packen, nennen wir es das "Fröhliche Einkaufserlebnis Gesetz".

[herbstrot]

Moin,

genau darüber hab ich mir auch schon Gedanken gemacht. Ist ja nicht nur der Stromausfall. Der Bediener könnte den TSE-USB-Stick einfach rausziehen. Dann gibts bei Start() keine Transaktionsnummer. Ohne Tranaktionsnummer auch kein Finish(). Was gehört dann auf dem Bon?
In der RKSV ist genau beschrieben was zu tun ist wenn die Sicherheiteinrichtung nicht verfügbar. Solche Angaben fehlen oder ich bin zu blöd diese zu finden :?

[Neumann]

Offen bleibende Transaktionen - aus welchem Grund (Programmabsturz, Stromausfall usw.) machen mir auch Sorgen. Man kann diese aus der TSE ermitteln, sinnvoll ist wohl diese nach einer Zeit x zu beenden, da es ein Limit für offene Transaktionen gibt das verhindert das neue Transaktionen gestartet werden können.

Zu Fehler: Da muss man einen so weit mir bekannt ist nicht weiter definierten Hinweis auf den Bon schreiben an statt es sonst übliche Signaturkauderwelsches.

[jaenicke]

Zitat:

Zitat von Neumann (Beitrag 1455922)

Offen bleibende Transaktionen - aus welchem Grund (Programmabsturz, Stromausfall usw.) machen mir auch Sorgen.

Die Transaktionsnummer muss doch eh für den DSFinVK Export gespeichert werden. Da kann die doch nicht in der TSE offen bleiben ohne dass eine entsprechende offene Rechnung an der Kasse existiert. Natürlich muss dann die Fehlerbehandlung entsprechend den Zustand behandeln.

Zitat:

Zitat von herbstrot (Beitrag 1455917)

Der Bediener könnte den TSE-USB-Stick einfach rausziehen. Dann gibts bei Start() keine Transaktionsnummer. Ohne Tranaktionsnummer auch kein Finish(). Was gehört dann auf dem Bon?

Nichts zur TSE (aber alle anderen Daten) und kein QR-Code. Zusätzlich empfiehlt es sich den Betreiber auf geeignetem Weg zu benachrichtigen, damit dieser dem Gesetz entsprechend schnellstmöglich die TSE wieder in Ordnung bringt.

Zitat:

Zitat von DeddyH (Beitrag 1455908)

Ich bin immer noch der Meinung, dass man die österreichische Lösung hätte übernehmen sollen, aber mich fragt ja keiner.

Wenn man die deutsche Lösung von Anfang an mit Experten erstellt hätte, hätte diese richtig gut werden können. Das Potential war da...
Und wenn man dann noch die Beleglotterie eingeführt hätte, wäre der Effekt auch viel größer gewesen.

[DeddyH]

Zitat:

Zitat von jaenicke (Beitrag 1455924)

Wenn man die deutsche Lösung von Anfang an mit Experten erstellt hätte, hätte diese richtig gut werden können.

Das heißt, im BSI sitzen keine Experten? :mrgreen:

[Rollo62]

Zitat:

Zitat von DeddyH (Beitrag 1455926)

Zitat:

Zitat von jaenicke (Beitrag 1455924)

Wenn man die deutsche Lösung von Anfang an mit Experten erstellt hätte, hätte diese richtig gut werden können.

Das heißt, im BSI sitzen keine Experten? :mrgreen:

Nein, die vom BSI sind im Moment auch Alle mit dem BER beschäftigt :-D

[jaenicke]

Zitat:

Zitat von DeddyH (Beitrag 1455926)

Zitat:

Zitat von jaenicke (Beitrag 1455924)

Wenn man die deutsche Lösung von Anfang an mit Experten erstellt hätte, hätte diese richtig gut werden können.

Das heißt, im BSI sitzen keine Experten? :mrgreen:

Doch schon, aber der Gesetzentwurf kam aber nicht von da. Die Technik für die TSE usw. funktioniert ja und ist auch soweit ich das beurteilen kann recht gut. Das Problem sind die Vorstellungen derjenigen, die das Gesetz ursprünglich entworfen haben. Denn das hätte schlicht logisch gar nicht funktioniert. Also wirklich überhaupt gar nicht...

Das, worüber wir jetzt sprechen, ist ja die aktuelle Version, die zwar nicht sonderlich schön, aber zumindest funktionsfähig ist, nicht der ursprüngliche Entwurf und der Stand wie er in das Gesetz kam...

Wenn du etwas zum Lachen haben möchtest, schau dir die Entstehung des Gesetzes und die ersten Fassungen ohne die Ausführungsverordnungen einmal an. Gut, mir ist da eher zum Weinen, aber lachen geht auch...

[DeddyH]

Ich kenne die Geschichte, ich war letztes Jahr auf einer DFKA-Tagung. Aber wir driften so langsam ab.