Closed uwap closed 5 years ago
Aus Kassenwartsicht würde ich mich über eine Möglichkeit freuen, Statistiken zu bekommen, gerne auch anonymisiert:
Ich würde die Produkte nach oben sortieren, damit die Leute eher über die Produktwahl gehen und nur wenn das Produkt nicht eingepflegt ist über die Beträge gehen. Dann bekommen wir vielleicht irgendwann mal ne grobe Chance, Bestand gegen Soll abzugleichen (zumindest im Groben)
Gibts technische Gründe das auf fnodcredit statt auf strichliste.org zu basieren? Da müssen wir dann wieder alle Bestände migrieren...
Migrationsscript für Strichliste -> Fnordcredit ist schon so gut wie fertig. Es gibt da durchaus technische Gründe. Das Fnordcredit hat nämlich schon fast das gesamte Featureset wodurch zumindest Serverseitig nur wenige Anpassungen gemacht werden müssen.
Für Statistiken überlege ich, ob wir entweder die Daten täglich ins Grafana überliefern wollen oder ob wir chart.js nutzen wollen, um die Statistiken im Frontend anzuzeigen.
Backendseitig muss da noch die Assoziierung von Transaktion zu Produkten korrekt passieren, um das ganze nach Produkt aufzuschlüsseln. Aber an sich hätte ich das Feature auch gerne, um beispielsweise auch festzustellen, welche Snacks wie gut gehen und welche man auf jeden Fall oder auf keinen Fall kaufen sollte.
Produkte nach oben sortieren klingt nach einer guten Idee!
Zur Ergänzung: Das Backend vom Fnordcredit wurde vom Stratum0 komplett neu geschrieben, daher hat es deutlich mehr Features als in der Version die wir hatten. Auch das Entropia hatte Fnordcredit geforkt und um einen haufen Funktionen erweitert. Ich versuche gerade das auch alles unter einen Hut zu kriegen, denn die neue Version ließe sich dann auch im Entropia und im Stratum0 aufsetzen.
Siehe auch: https://github.com/entropia/fnordcredit https://github.com/marudor/fnordcredit
Das neue Fnordcredit basiert genau so wie Strichliste auf SQLite, was die Migration einfacher macht.
In Anlehnung an tabascoEyes post wurde ich mir einen check-in fur produkte wunschen: Name, anzahl, einkaufspreis der box, verkaufspreis jeweils, datum. Zur barcode Integration kann man dann noch den einzel barcode scannen.
On 19 Feb 2018 23:43, "uwap" notifications@github.com wrote:
Ich arbeite zur Zeit an einem neuen Kassensystem. Siehe https://github.com/uwap/fnordcredit-frontend und https://github.com/silsha/fnordcredit.
Ziel sind folgende Features:
- Auflistung der letzten Transaktionen
- Transaktionen anonymisierbar (dann sind sie auch nicht mehr im Profil sichtbar)
- Barcode Support
- Suche, Sortierungen
Aktueller stand des Frontends [image: fnordcredit20neu] https://user-images.githubusercontent.com/2212422/36399914-5df05f5c-15ce-11e8-9cbc-6e6a47f836c1.png [image: fnordcredituserdetail] https://user-images.githubusercontent.com/2212422/36399993-b26d5378-15ce-11e8-8e19-2949cb1c0306.png
Ideen, Vorschläge, Wünsche etc. können hier gesammelt und diskutiert werden.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/raumzeitlabor/rzl-tuwat/issues/185, or mute the thread https://github.com/notifications/unsubscribe-auth/AAvaC2sM2og6rDUj3D7jMAYVq-eIcw-yks5tWfkugaJpZM4SLMKP .
Meine Überlegung war, ob man irgendwie einen Admin Modus macht, wo man das einstellen kann, genau so wie den höchsten negativen Betrag pro Nutzer etc., ich bin mir aber nicht sicher, wie man so ein Admin Interrface gestalten würde.
Eine Idee wäre, dass User einen Admin Flag haben und nutzer die Admin sind können in ihren Einstellungen alles ändern. Aber ich finde, das ist auch eher suboptimal.
Die andere Variante ist im Strichliste Ordner auf cashdesk.rzl scripte für sowas bereit zu stellen, aber auch das finde ich eher suboptimal.
Habt ihr bessere Ideen?
dunno. Im Grunde basiert das ganze Strichlistenkonzept auf Vertrauen. Vertrauen, dass alle korrekt abrechnen, Vertrauen, dass keiner auf anderen Accounts außer dem eigenen bucht, Vertrauen, dass die Leute das System nicht als Dispokredit mißbrauchen (HUST), Vertrauen dass keiner einen anderen User löscht,...
Also letztendlich sind da irgendwelche Admin Rechte dann recht sinnlos. Für so Dinge wie "maximales Minus" macht es dann schon wieder Sinn, wenn man sowas nicht im Code festlegen will.
==> keep it simple?
Wie wuerde denn ein fall aussehen, in dem wir einem subset der accounts einen anderen max-dispo zuweisen?
On 21 Feb 2018 17:18, "TabascoEye" notifications@github.com wrote:
dunno. Im Grunde basiert das ganze Strichlistenkonzept auf Vertrauen. Vertrauen, dass alle korrekt abrechnen, Vertrauen, dass keiner auf anderen Accounts außer dem eigenen bucht, Vertrauen, dass die Leute das System nicht als Dispokredit mißbrauchen (HUST), Vertrauen dass keiner einen anderen User löscht,...
Also letztendlich sind da irgendwelche Admin Rechte dann recht sinnlos. Für so Dinge wie "maximales Minus" macht es dann schon wieder Sinn, wenn man sowas nicht im Code festlegen will.
==> keep it simple?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/raumzeitlabor/rzl-tuwat/issues/185#issuecomment-367381217, or mute the thread https://github.com/notifications/unsubscribe-auth/AAvaC19O10L6y2Se4RfGjJDGjoIov1hJks5tXEHjgaJpZM4SLMKP .
wen fragst du? In meinem Kopf kann das so bleiben wie bisher. Einmal fest im backend eingestellt, hart.
Ich hab die Frage allgemein an die Diskussion intendiert. Die Antwort ist genau so wie ich das erwartet hatte
On 22 Feb 2018 16:43, "TabascoEye" notifications@github.com wrote:
wen fragst du? In meinem Kopf kann das so bleiben wie bisher. Einmal fest im backend eingestellt, hart.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/raumzeitlabor/rzl-tuwat/issues/185#issuecomment-367721947, or mute the thread https://github.com/notifications/unsubscribe-auth/AAvaC3od7ntetn7Mro5u80H_NE5rTH6fks5tXYsxgaJpZM4SLMKP .
Sobald wir ein neues / wieder funktionierendes Kassentablet haben, werde ich das neue Kassensystem mal parallel zum alten aufsetzen. Das ganze wird ein Testversuch und die Daten werden nachher wieder gelöscht. Wir kennen das Spiel ja schon. @Drachenkaetzchen verkauft gerade ihren alten Barcodescanner für 71€. Ich würde den gerne fürs RZL holen. Den Barcodescanner hatte ich bereits benutzt um die Barcodefunktion zu implementieren und zu testen.
Wir müssen unbedingt darauf achten, dass das neue Kassentablet unbedingt entweder einen USB Port hat oder USB On The Go fähig ist.
Spricht eigentlich irgendwas dagegen einfach einen RasPi 3 mit touch display zu nehmen?
@tabascoeye kann man schon machen, oftmals kosten größere Displays aber soviel wie ein ganzes Tablet, und man muß einen Browser im Headless-Mode starten, was bisschen frickelig ist
Fnordcredit ist deployed, weitere Issues zu dem Thema werden in https://github.com/fnordcredit/fnordcredit/issues und https://github.com/fnordcredit/frontend/issues verwaltet.
Ich arbeite zur Zeit an einem neuen Kassensystem. Siehe https://github.com/uwap/fnordcredit-frontend und https://github.com/silsha/fnordcredit.
Ziel sind folgende Features:
Aktueller stand des Frontends
Ideen, Vorschläge, Wünsche etc. können hier gesammelt und diskutiert werden.