Gastro-MIS GmbH

L3-Artikelverknüpfung auf Bar/Unbar

Beschreibung:

Falls man z.B. das Trinkgeld mit einem Artikel verknüpft, dieser Artikel aber auf Bargeld geht, wurde das Trinkgeld wie anderer Umsatz storniert. Das führt aber zu Problemen, da das Trinkgeld in diesem Fall auf Bargeld geht, der Storno aber auf Umsatz.

Gelöst wurde es, indem in solch einem Fall ein Storno erstellt wird, welches auch auf Trinkgeld geht.

Versionen des Bugfixes:  L3- Server 1.7.5.30563 

Neu erstellen eines Tisches nach Erzeugen einer Gutschrift wird nicht ausgeführt.

Beschreibung:

Wird in LINA POS die Funktion 212 (Zahlung löschen) ausgeführt, werden intern eine Vielzahl von Funktionen ausgeführt. Der bereits abgeschlossene Tisch und somit die abgeschlossene Rechnung, wird komplett als Gutschrift erstellt, alle Buchungen werden mit umgekehrtem Vorzeichen wiederholt. Dieser Vorgang erfordert zwei Transaktionen auf der TSE, es müssen also vier Signaturen erstellt werden. Die Gutschrift wird wie auch die Rechnung zuvor gedruckt. Anschließend werden alle Buchungen des ursprünglichen Tisches auf einem neuen Tisch wiederholt, mit Ausnahme der Zahlung(en) und des Rechnungsdrucks. Die Funktion 212 löscht also nicht wirklich die Zahlung, sie erzeugt vielmehr eine Gegenbuchung und boniert den Tisch ohne Zahlung anschließend neu, sodass der Tisch dann auf eine andere Zahlart erneut abgeschlossen werden kann. Da alle Vorgänge auf der TSE abgesichert und in der Datenbank erfasst werden müssen, ist dieser Vorgang mit der aufwendigste Vorgang innerhalb von LINA POS. 

Bis zu den unten beschriebenen Versionen konnte es bei Systemen mit hoher Last auf der Datenbank (viele gleichzeitige Aktionen mehrerer Kellner:innen) in sehr seltenen Fällen dazu kommen, dass nach Erstellen der Gutschrift, das neu Erstellen des Tisches nicht durchgeführt werden konnte, da die Datenbank durch andere Operationen den Zugriff auf die nötigen Tabellen gesperrt hat (table lock bei Schreiboperationen). Bei der Nutzung der Funktion 212 wurde in diesem Fall eine Fehlermeldung (Cloud not execute statement) angezeigt und entgegen dem zu erwartenden Verhalten stand der Tisch im Anschluss nicht zum erneuten Abschließen zur Verfügung. Da die Gegenbuchung (Gutschrift) erfolgt ist, sind im Ergebnis sowohl die Umsatzbuchungen als auch die Zahlungen auf 0. 

Versionen des Bugfixes:  01.06.04.25683 Build 240502; 01.07.04.25684 Build 240502 

Belegstranskation doppelt auf TSE

Beschreibung:

Falls ein Ebon auf einem Tisch gedruckt wird, wo es bereits eine Belegstransaktion gibt, wird die Transkation beim Ebon erneut durchgeführt. Das äußert sich schlussendlich beim DSFInV_K und TAR-Export.

Beim Tar-Export wären dann die Belegs-Umsätze mehrfach drinnen.

Beim DSFinV-K Export würde es dann Transkationen vom Typ "Beleg" mit "DUP" im Namen geben. DUP steht in diesem Fall für Duplikat. Auch würde AmadeusVerify in diesem Fall einen Fehler ausgeben, dass die Daten in DUP nicht mit den TSE-Daten übereinstimmen. Erklärung dafür ist, dass diese DUP-Transkationen von uns ohne Daten exportiert werden, damit die Umsätze nicht doppelt exportiert werden. 

Versionen des Bugfixes:  Server 01.06.04.29496 Build 241010
Server 01.07.04.29497 Build 241010 
Server 01.07.05.29498 Build 241010   

Bezahlter Tisch als Belegabbruch interpretiert

Beschreibung:

Wenn mit Delivery gearbeitet wird und ein Tisch wird erstellt, boniert und nur zum Teil gezahlt, kommt es beim Tagesabschluss dazu, dass der Restbetrag als Bar abgeschlossen wird. Es wird aber keine Rechnung erzeugt und der Tisch wird auf der TSE als AVBelegabbruch behandelt. 

Das ist passiert, falls es eine kleine Differenz bei der Preisberechnung zwischen lokalem Server und Delivery-Server gegeben hat. Dadurch war noch 1 Cent auf dem Tisch offen, dieser konnte aber die Artikel nicht mehr stornieren, weil schon ein Zahlungsweg auf dem Tisch ist. Mit dem Fix wird der Tisch weiterhin abgeschlossen, aber es wird auch eine Rechnung gedruckt und der Tisch wird als Kassenbeleg auf der TSE abgesichert.

Versionen des Bugfixes:  Server 01.06.04.30029 Build 241104

Server 01.07.04.30030 Build 241104

Server 01.07.05.30031 Build 241104

DUP-Transaktion AVSonstiges

Beschreibung:

Es konnte passieren, dass die Logik zum Setzten der negativen Documentnummer mehrfach ausgeführt worden ist. Das führt dann auch zu einem mehrfachen Absichern auf der TSE.

Versionen des Bugfixes:  Server 01.06.04.30029 Build 241104

Server 01.07.04.30030 Build 241104

Server 01.07.05.30031 Build 241104

Bar/Unbar stimmen auf der TSE-Absicherung nicht

Beschreibung:

Falls nicht die standardmäßige Finanzart "Bargeld" für Bargeldfinanzwege verwendet wurde, wurden diese auf der TSE als "Unbar" abgesichert. Das führt zu einem Fehler in der Validierung. 

Versionen des Bugfixes:  Server 01.06.04.30029 Build 241104

Server 01.07.04.30030 Build 241104

Server 01.07.05.30031 Build 241104

Bar/Unbar stimmen auf der TSE-Absicherung nicht

Beschreibung:

Es wurde mit FUNC 215 von Bar auf Unbar oder umgedreht gewechselt nachdem Rechnungsdruck. In dem Fall sollte aber eine Gutschrift erstellt werden und alles neu auf der TSE abgesichert werden.

Leerer Tisch bei Tagesabschluss nicht richtig geschlossen

In diesem Fall wurde der Tisch zwar geschlossen, aber ohne dass z.B. das "documentdate" gesetzt wurde, oder der Tisch auch als "Leerer Tisch" auf der TSE abgesichert wurde.

Das führt im Export dazu, dass die Zeitstempel auf dem Tisch der 1.1.1970 sind bzw. dass der Tisch als "Schließen von verwaisten Transaktionen" auf der TSE abgesichert worden ist.

Versionen des Bugfixes:  01.05.03.11092 Build 220719

Zahlung während externer Zahlung

Während eine externe Zahlung lief, wurde der Tisch abgeschlossen. Nachdem die externe Zahlung durchging, wurde diese auch verbucht. Das führt zu einer Aussenstandsdifferenz und potentiell wurde auf der TSE nur eine der Zahlungen abgesichert.

Gleichzeitig zwei Zahlungen

Es konnte vorkommen, dass zwei Zahlungen gleichzeitig angestoßen wurden (von verschiedenen Terminals). Diese wurden dann beide verarbeitet.

Absicherung von 0.00:Bar/Unbar

Es konnte vorkommen, dass bei stornierte Zahlungen auch 0.00 Zahlungen auf der TSE abgesichert worden sind, obwohl 0.00 Zahlungen entfallen müssen. Das ist ein L3 spezifisches Problem und wurde gelöst.

Versionen des Bugfixes: 01.07.04.25830

Storno hat nicht gegriffen

Es wurde ein Storno durchgeführt, dieses Storno wurde aber intern nicht richtig rausgerechnet. Dadruch konnte man den Artikel wieder und wieder stornieren. Diese zusätzlichen Stornos sind nicht auf der TSE abgesichert, sind aber im Export enthalten.

Sofortstorno hat anderen Steuersatz als der stornierte Artikel

Auf der Rechnung sollte alles passen, bei verschiedenen Exporten über diesen Zeitraum kann es aber dadurch zu anderen Steuersummen kommen.

Sofortstorno Tender mit Preis

Es konnte passieren, dass ein Tender mit Preis storniert wird, der Preis des Stornos aber 0€ beträgt und es so zu einer Aussenstandsdifferenz kommt.

Rabattpreis von Storno

Es konnte passieren, dass ein Artikel einen Rabatt hatte und beim Stornieren wurde hat dieser Rabatt einen falschen Preis bekommen.