Gastro-MIS GmbH

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:  01.06.04.xxxxBuild xxxx; 01.07.04.xxxxBuild xxxxx

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:  01.06.04.xxxxBuild xxxx; 01.07.04.xxxxBuild xxxxx

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:  01.06.04.xxxxBuild xxxx; 01.07.04.xxxxBuild xxxxx

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:  01.06.04.xxxxBuild xxxx; 01.07.04.xxxxBuild xxxxx

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

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.

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.