Nicht serviert / unbezahlt wird angezeigt trotz bezahlt!

[Ingo]

Hallo Stefan,

wir ein Musikverein nutzen deine Software schon zum dritten Mal und es hat immer super funktioniert!
Im Moment nutzen wir die 2.4.6 Version! Bei der jetzigen Veranstaltung hatten wir an bestimmten Tischen
Artikel die als nicht serviert/unbezahlt standen obwohl sie bezahlt waren! Also vermutlich dann nicht serviert!

Unser Ablauf ist:

Bestellung über Mobilansicht:
Tischnr auswahl
Artikel wählen
Kassen Button drücken -> Bon's werden gedruckt!
Es wird im Kassenbild abgerechnet mit Nur Zahlung -> fertig!

Das funktioniert einwandfrei!

Ich meine das bei den nicht servierten Artikeln ich zwischendurch Bestellungen von anderen Tischen gemacht habe
und die besagten vom tisch 6 erst später kassiert habe! Dann bleiben sie wohl als nicht serviert stehen!

Haben wir da noch was falsches eingestellt oder ist das in der Version ein Fehler!
Für deine Hilfe wäre ich dir sehr dankbar!

Gruß Ingo

[pichel]

Hallo Ingo,

die Bedingung soll als "Nicht serviert" ODER "nicht bezahlt" verstanden werden. Wenn also Artikel nicht bezahlt wurden, wie du sagst, sollen sie auch dort stehen. Es kann aber durchaus sein, dass ich da bei den vielen Kombinationen (bezahlt, serviert, zubereitet, storniert, storniert und neu bestellt) nicht alles korrekt in der Tabelle abgedeckt habe.

Außerdem hat die Einstellung der Kategorie einen Einfluss. Wenn du dort angegeben hast, dass die Artikel nicht die Bereitstellungsansicht durchlaufen sollen, werden sie auch nicht dort stehen, wenn sie bereits bezahlt wurden. Damit kann sich die Liste also je nach Artikel anders verhalten. Aber auch da mein Hinweis: Das ist ziemlich alter Code und ich möchte meine Hand nicht dafüpr ins Feuer legen, dass das noch alles stimmt und nicht spätere Codeänderungen an anderer Stelle die Funktion kaputt gemacht haben. Vielleicht machst du sonst einfach ein Backup "Alles (ohne Logs)" zu einem Zeitpunkt, wo nach deiner Ansicht ein falscher Inhalt in der Liste steht, schickst mir das zu mit dem Hinweis, was du erwartest und ich kann es mir hgenauer anschauen.

Gruß,

Stefan

[Gast]

Hallo Stefan,

danke für die schnelle Antwort!

Wir testen das Kassensystem und wollen ein unter unseren Einstellungen optimales und funktionierendes System
nach dem Motto never change a running system, da wir das System zu unserem 100 jährigen Jubiläum nächstes Jahr
einsetzen wollen!
Deshalb bin ich mit neuen Versionen auch immer vorsichtig!
Denkst du wir sollten auf jeden Fall auf die aktuelle Version wenn du sagst es sei recht alter Code!
Oder was empfiehlst du uns?

Gruß Ingo

[pichel]

Hallo Ingo,

nein so war das nicht gemeint. Was ich sagen wollte, ist, dass die einzelnen Features der Software zu unterschiedlichen Zeiten einprogrammiert wurden. Ich versuche zwar durch automatisierte Regressionstests sicherzustellen, das neue Versionen nicht alte Funktion kaputt machen, aber die Testabdeckung ist bei weitem nicht komplett und es kann natürlich immer passieren, das im Laufe der Zeit Funktionen, die früher funktioniert haben, irgendwann durch irgendein Update kaputt gehen.

Im Changelog auf der Downloadseite kannst du genau nachvollziehen, welche Änderungen in welcher Version gemacht wurden. Wenn zwischen der aktuellen Version, die du nutzt, und der neuesten, keine Änderungen programmiert wurden, die für dich interessant sind, dann mach ein Update wahrscheinlich gar keinen Sinn für dich.

Jedenfalls habe ich schon länger nicht mehr an dem Quellcode für die Liste der nicht servierten oder unbezahlten Artikel gearbeitet. Ein Update wird dir in diesem Zusammenhang also nicht helfen. Wenn es aber ein Bug ist, den ich bei mir mit deiner Hilfe nachvollziehen kann, werde ich aber versuchen, diesen in einer der zukünftigen Versionen zu beheben.

Vielleicht noch eine Anmerkung: Wenn du Php 8 nutzt, ist ein Update auf jeden Fall sinnvoll, weil ich ach 2.4.6 noch Kompatibilitätsprobleme gelöst habe.

Gruß,

Stefan

[Gast]

Hallo Stefan,

ja wir sind auf PHP 8.1 unterwegs und ich habe nun doch auf die aktuelle Version geupdatet!
Bisher habe ich das nicht geschafft den Fehler nachzustellen! Falls es wieder vorkommt melde ich mich nochmal
und werde dir dann die Konfiguration schicken!

Danke für deine Unterstützung und das tolle Programm!

Gruß Ingo

[Ingo]

Hallo Stefan,

nun ist nächste Woche unser großes 100 Jahre Musikverein Fest und ich wollte heute meine Bedienungen schulen.
Jetzt ist das Problem auch in der Version 2.8.0 aufgetreten bzw. immer noch vorhanden!

Im Prinzip werden Waren als nicht serviert angezeigt, was aber schon bezahlt wurde!
Das bringt die Bedienungen durcheinander! Könnte ich die anzeigen irgendwie per SQL löschen?

Gruß Ingo

[Ingo]

Hallo Stefan

ich habe noch viel getestet und ich kann den Fehler jetzt nachstellen!

Ich Tippe auf einen Tisch über Bestellungen z.B. ein Bier und drücke dann Kasse!
Ich zahle im Kassenbereich noch nicht! Geht man jetzt über Hauptmenü auf Kasse
und zahlt dort ist der Artikel auf dem Tisch für immer nicht serviert!

MfG Ingo

[irrsinn.de]

Hallo,

wir haben den selben Effekt. Ich dachte zunächst es hängt damit zusammen, dass in den Kategorieneigenschaften bei Artikeln auf "Bereitstellung nicht Durchlaufen" umgestellt werden muss.

Bildschirmfoto 2024-06-09 um 15.06.09.png (87.29 KiB) 5248 mal betrachtet

Daran lag es aber nicht. Ich habe gestern alles umgestellt und schaue gerade mal in dem Restaurant vorbei und siehe da:

Bildschirmfoto 2024-06-09 um 15.09.37.png (62.58 KiB) 5248 mal betrachtet

Wie stellt man das aus? Was mich verwirrt ist, dass es nur in einem der 5 Restaurants auftaucht. Bei den anderen nicht und wir haben schon x-Mal die Einstellungen verglichen.

Gruß Lutz

[Ingo]

Hallo Lutz,

ich habe mit Stefan gesprochen und er vermutet das es ein Bug ist, er wird danach schauen!

Es passiert nur wenn man über die Menüauswahl rechts oben in "Kasse" geht und dort Tische abrechnet!
Macht man die Abrechnung über das Bestellmenü drückt dort Kasse dann nicht!

Gruß Ingo

[Skifan]

Hallo zusammen,
wir hatten das Problem auch bei unserem Vereinsfest am Wochenende. Unsere Bedienungen haben dann häufig den mit einem "Häkchen" markierten Artikel entfernt und es wurden dadurch immer Stornobons gedruckt. Dies hat dann häufig für Verwirrung gesorgt.

Unser Workaround war dann so, dass wir in der Tabelle "ordersprinter_queue" von Hand das gleiche Datum und die gleiche Uhrzeit gesetzt haben, wenn in Paidtime ein Datum und eine Uhrzeit vorhanden war.

Das ganze könnte man jetzt noch mit einem kleinen Skript perfektionieren, welches im Hintergrund alle x Sekunden aufgerufen wird, bis Stefan den Fehler gefunden hat

Viele Grüße Skifan