TSE swissbit Problem mit Rechnung „Splitten“ für die Gastronomie

  • VB6

Es gibt 7 Antworten in diesem Thema. Der letzte Beitrag () ist von Harry55.

    TSE swissbit Problem mit Rechnung „Splitten“ für die Gastronomie

    Hallo Gemeinde

    Bekannt sind mir:
    worm_transaction_start = Startzeit festhalten
    worm_transaction_update = weitere Getränke dazu addieren
    worm_transaction_finish = diese Rechnung kassieren

    Wenn ich jedoch eine Rechnung Splitten muss, habe ich ein Verständigungsproblem
    Beim Kassieren, sei es auch nur ein Teil der Rechnung, ist die „Transaktions-Nummer“ weg
    Der Rest kann nicht mehr kassiert werden

    Gibt es eine Methode nur ein Teil zu kassieren ohne die „Transaktions-Nummer“ zu zerstören und anschließend den Rest zu kassieren.
    @Harry55 Da die "Transaktion-Nummer" nicht unter den Dir bekannten Größen aufgelistet ist, frage ich mal ketzerisch:
    Ist dieese Nummer vorhanden, wenn die Rechnung nicht gesplittet wird?
    Ansonsten ist der Hintergrund des Zustandes / Vorhabens zu wenig beleuchtet.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    @RodFromGermany
    Ja die „Transaktion-Nummer“ ist bekannt
    Bei „worm_transaction_start“ bekommt man die Nächst höhere Transaktion Nummer von der TSE zugewiesen.
    Alle Buchungen auf diesen Tisch „worm_transaction_update“ erfolgen mit dieser Transaktion Nummer.
    Auch die Kassierung erfolgt mit dieser Nummer.
    Danach ist diese „Transaktion Nummer“ verbraucht, es funktionieren keine zusätzlichen Buchungen oder Kassierungen mit dieser Nummer.
    Ich finde jedoch keine Möglichkeiten einer Teilabrechnung „Splitten“
    @Harry55 Das ist jetzt eher eine juristische Angelegenheit, da das Finanzamt da ggf. mit reinspielt.
    Muss da ggf. eine neue Transaktionsnummer generiert werden?
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    @RodFromGermany
    Programmtechnisch wäre eine zusätzliche generierte „Transaktion Nr.“ möglich.
    Das Splitten mit der vorhandene „Transaktion Nr.“ vorzunehmen und zugleich eine neue Nr. Beantragen.
    Mit der neue „Transaktion Nr. “ dann den Rest kassieren.

    was ist jedoch das Ergebnis:
    Auf der ersten „Transaktion Nr. “ stehen 6 Getränke
    und eine Kassierung die nicht der Gesamtsumme entspricht.

    Auf der neuen „Transaktion Nr. “ stehen 0 Getränke
    und eine Kassierung auf die nix bebucht würde.

    das kann nicht die Lösung sein, frage mich was sich „die Herausgeber“ dabei gedacht haben.
    Aber vielleicht gibt es ja eine andere Lösung die ich nicht kenne?
    @Harry55 Wie wird das denn anderswo gehandhabt?
    ====
    Mit dem vorhandenen Code und einer exakten Aufgabenstellung ist das alles kein Problem.
    Falls Du diesen Code kopierst, achte auf die C&P-Bremse.
    Jede einzelne Zeile Deines Programms, die Du nicht explizit getestet hast, ist falsch :!:
    Ein guter .NET-Snippetkonverter (der ist verfügbar).
    Programmierfragen über PN / Konversation werden ignoriert!
    @Harry55

    Die Finanz hat erst später festgestellt, dass das mit lang anhaltenden Bestellvorgängen (so nennt man das in der Gastronomie) technisch nicht so einfach zu lösen ist, ist aber nicht von der "Technik" abgerückt.

    Ich habe das ganze mit einer Middleware umgesetzt und die haben ein lokales Webservice dem man alle Daten übermittelt und das dann vieles regelt.

    Aus Copyright-Gründen darf ich Dir hier nicht den ganzen Text und Grafik posten, aber ein Ausschnitt hilft Dir sicher die richtigen Informationen im Netz zu finden:


    Wir empfehlen Nutzung der Abläufe der Erleichterungsregelungen, da das XXXXX dadurch viele Abläufe übernehmen kann, die sonst von der Kasse erfüllt werden müssten.
    ...

    Für lang anhaltende Bestellvorgänge müsste ein /updateTransaktion aufgerufen werden. Als Erleichterung kann man wie in der Abbildung gezeigt wird statt einem Update auch ein /finishTransaction mit Typ "Bestellung" senden (xxxx).
    Vorteile: Die Updates entfallen, somit muss sich die Kasse keine Transaktions ID speichern. Es können gesplittete Rechnungen dargestellt werden.
    Voraussetzung: Zusätzlich muss der Startzeitpunkt (xxxx) der ersten "Bestellung" am Bon gedruckt werden.


    Wenn mans selbst (ohne Middleware) programmiert, dann vielleicht folgender Tipp:

    Update transaction nach jeder Änderung der Tischbuchung.
    Splittrechnung unterscheiden sich nicht von normalen Rechnungen.
    Im DSFinVK Export kann man Splittrechnungen durch die einheitliche Zuordnung zur Tischnummer erkennen.
    Die Splittrechnungen haben den selben Start-Transaction Zeitpunkt wie die erste Bestellung am Tisch.

    Erst wenn die letzte Position abgerechnet wurde, und der Tisch dann für den nächsten Gast bebucht wird, dann setzt man wieder eine neue Start-Transcaction.

    Fazit: Man muss im DSFinVK Export eindeutig erkennen, welche Transaktionen zu einer langanhaltenden Bestellung alles dazugehören.

    Ein Sonderfall ist z.B. wenn ein Produkt von einem Tisch auf einen anderen transferiert wird.
    Dann gibts am Quelltisch ein Transaction-Update und am Zieltisch ebenfalls ein Transaction-Update. Ausser dort war vorher noch nichts gebucht, dann muss dort ein Transaction-Start generiert werden.

    Alles nicht so trivial und SEEEEEEHR viel Arbeit.

    Liebe Grüße
    Roland Berghöfer

    Meine aktuellen und kostenlos verwendbaren Tools (mit VB.NET erstellt): bocomponent.com | freeremarkabletools.com

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „dive26“ ()

    Neu

    Danke für eure Ausführungen.
    Bin zu keiner Lösung betreff „Splitte“ gekommen

    Beim kassiere oder Splitte nutze ich doch die beim TransaktionStart vergebene Transaktionsnummer.
    Und eben diese Transaktionsnummer ist nach dem Kassiervorgang ungültig.
    Was zwar richtig ist, denn dieser Vorgang muss ja auf dem Beleg erscheinen.
    transaction_finish = Transaktion geschlossen

    Nach dem splitten ist die Transaktionsnummer aber auch ungültig
    transaction_finish = Transaktion geschlossen
    Es stehen jedoch noch 2 Getränke offen, die ich nicht mehr kassieren kann.
    Auf dem Bon kann ja nicht die gleiche Transaktionsnummer stehen.

    Natürlich kann ich den Startzeitpunkt der ersten "Bestellung“ anwenden
    Jedoch nicht die gleiche Transaktionsnummer