Kassensystem

Diese Seite ist im Rahmen der Erstellung eines Kassensystems für die Freitagsrunde entstanden. Die Grundidee war dabei für den Touchscreen (oder eine andere Plattform) in unserem Raum eine Software zu erstellen, mit der mehrere Nutzer ihren Getränkekonsum und die dabei entstehenden Kosten verwalten können. Um die Anforderungen an ein solches System zu sammeln und zu koordinieren ist dieses Seite da.

k4ever

k4ever ist die aktuelle implementation des Kassensystems der Freitagsrunde. Momentan befindet es sich noch sehr stark in Entwicklung, ist aber vollständig Funktionsfähig. Der Kern ist die Webseite http://k4ever.freitagsrunde.org, auf der jedes Item gekauft, der Kontostand und Einstellungen verwaltet werden kann. Für Requests von außen kann die REST-Api benutzt werden. Diese ist ausführlich Dokumentiert: https://k4ever.freitagsrunde.org/media/docs/index.html

Für die Weiterentwicklung steht ein Trac bereit

• Code: git clone git://git.someserver.de/git/k4ever
• Trac/Bugs: http://k4ever.someserver.de

Plugins

• Gnome-Panel: Kassenstand anzeigen, dropdown menü für aktionen? Regelmäßige Updates.
  • Tom arbeitet dran:
  • Schnellkaufen der fünf am meisten gekauften Items des Users
  • Einloggen mit Authblob || (username && password)
  • Mitmachen -> E-Mail
• Panic Button: Für Mate kaufen. Fenster-Global-Hotkey strg+alt+M(ate)?
• Android App: Obviously
  • Widget für Matekauf
  • Widget für Kontostandanzeige (Kombination möglich)
  • Die drei Faces (Meistgekauft, Von dir meistgekauft, zuletzt gekauft) in der App
• Achievements: "n* Mate gekauft", "Mate-Spreeee!", "Uuultra-Mate!", "Allstar", "KontoMaster (incremental)", "IceMan!/Frosty", "Promille", "13,37€, 42,21€, 23€...90,01€", "Achievement-Farmer(n-mal)",
• Statistik: Kalorien, Timetable - wann häufig gekauft,

Fehlende Barcodes

• Eis
• Opalix
• Spendenbuttons
• Sticker
• Tkroenert

Policy für Gastaccounts

Gäste können in k4ever auf Anfrage einen Account bekommen, wenn er denn benötigt wird, d.h. wenn man öfters da ist. Der Accountname setzt sich dann aus g_ und einem Nickname (möglichst kein allgemeiner Name wie "Hans" oder "Peter") zusammen. Gäste sollten keinen negativen Kontostand haben, dies wird aber vom Kassensystem nicht enforced.

Hochkomplexe Planungsideen

WARNUNG WARNUNG WARNUNG Ab diesen Punkt sind hauptsächlich Utopien und Planungsideen zu finden

Generelle Fragen

soll das Kassensystem auch für Besucher sein

• Pro
  • Zusammenrechner bei groesseren Bestellungen.
  • Man sieht wieviel Geld in der BAR-Kasse seien sollte.

• Con
  • zu aufwändig

Im Abschnitt Rollen steht ein Vorschlag für die Lösung des Problems

Anforderungen

harte Anforderungen

Das soll das System unbedingt leisten

• Der Frundler soll eine Übersicht bekommen was er der Frunde schuldet / wieviel Restguthaben er noch hat
• Überwachen der maximalen Kalorienzufuhr pro Tag/woche - überwachen eines Ernährungsplanes
• Verhindern von Indikationen nach ICD-10 Klassifikation F15.3 (langsames Ausschleichen)
• Verhinderung von Über und Unterdosierung von 1,3,7-Trimethyl-3,7-dihydro-1H-purin-2,6-dion

weiche Anforderungen

sind für die 1.x-Reihe nicht ganz so wichtig

• Fremdbuchungen à la "bring mir mal was mit" (gleich Feld [Gebucht von] oder so mit einbauen)
• Das Getränk wird am Terminal per Barcode-Scan eingegeben
• Anstatt einer Frunden-geldkarte wird per RFID die Mensakarte genommen
• Getränke/Speisekarte als PDF exportierbar machen um sie an den Kühlschrank zu hängen
• Achivement-System für z.B. 10 Mate in Reihe/Tag (oder ggf. Gesundheitswarnung)
• ...

Interface/Plattform

Für die Umsetzung sollte zumindest klar sein was später rauskommen soll:

• Touchscreen
  • muss erst wieder Touch haben --Jörg F 10:47, 26. Sep. 2010 (CEST)
    • leider läuft der Touch nur unter nem extrem alten X --Jungnickel 10:57, 26. Sep. 2010 (CEST)
      • Ja und nein. Ich habe ihn in der Konsole mit gpm zum Laufen gebracht, gpm kann einen socket für X zur Verfügung stellen, wo die Daten rausfallen. Also gpm als Proxy. --Florian 14:19, 26. Sep. 2010 (CEST)
        • Das ist ne gute idee... warum nicht gleich auf X verzichten? In der C-Base haben sie auch nur text-mode interfaces fuer ihr kassensystem, und jeder ist zufrieden mit. Ist doch viel geekiger :D --Andy[DE]
  • für jeden zugänglich --Jörg F 10:47, 26. Sep. 2010 (CEST)
  • Leichter Zugang für Gäste und schnelle Mate trinker/käufer --Jungnickel 10:57, 26. Sep. 2010 (CEST)
• Browser
  • man muss nen Laptop mit Internet dabei haben --Jörg F 10:47, 26. Sep. 2010 (CEST)
  • es können parallel Getränke gekauft werden --Jungnickel 10:57, 26. Sep. 2010 (CEST)
  • den Verbrauch und Kontostand sollte einsehbar sein ohne an den Touchscreen zu gehen. --Jungnickel 10:57, 26. Sep. 2010 (CEST)
  • Komplexere Seiten (Geld aufladen etc) sind vllt. leichter für den Browser zu implementieren--Jungnickel 10:57, 26. Sep. 2010 (CEST)
• Konsole
  • wird wohl eher nicht angenommen da zu aufwändig

Use cases

Der Warenverwaltungsaspekt fehlt hier noch völlig

Man sollte hier vielleicht sowas wie die (nummerierten) Haupt-Usecases rauspellen und unten dran eine Liste mit den Varianten stellen (die CLI-Fälle sind vermtl. alle Varianten der Kiosk-Fälle)

1. Frundler konsumiert:
   1. Der Frundler authentifiziert sich am System
   2. Der Frundler sagt dem System er kauft ein Getränk
   3. Das System belastet das Konto des Frundlers mit dem genommenen Getränk
2. Gast konsumiert:
   1. Der Gast sagt dem System er kauft ein Getränk.
   2. Der Gast legt den zum Getränk passenden Betrag in die Barkasse
   3. Der Gast nimmt sich das Getränk
3. Bucher laedt Frundlerkonto auf
   1. Der Frundler gibt dem Bucher $Geld Euro
   2. Der Bucher authentifiziert sich am System
   3. Er hebt den Betrag vom Buchungskonto ab
   4. Er laedt das Geld auf das Frundlerkonto
4. Bucher leeren Kasse
   1. Der Bucher authentifiziert sich am System
   2. Der Bucher nimmt das Geld aus der Barkasse
   3. Der Bucher bucht das Geld vom Barkassenkonto auf sein Konto
5. Bucher gibt Geld an Kassenwart weiter
   1. Der Bucher gibt dem Kassenwart (auch per Banktransfer) das gewartete Geld
   2. Der Kassenwart authentifiziert sich am System
   3. Er entlastet das Konto des Buchers

CLI-Fälle der obigen Varianten (alle?)

Folgende Faelle werden nur vom Admin im Auftrag des Getraenkewartes durchgefuehrt

• Ein neues Getränk anlegen
• Den Preis eines Getränks verändern

Rollen

Es gibt also folgende Rollen: Rollen: Gast, Frundler, Bucher, Kassenwart

Kommentare:

• Brauchen wir wirklich einen Bucher und einen Kassenwart (als Rolle)? Die Rolle des Buchers scheint mir überflüssig und auch für den Bucher zu stressig. Da eh auch jeder einfach so ohne zu Bezahlen Mate klauen könnte, wäre ein Bucher der wie ein Barman darauf achtet ob wirklich bezahlt wird schon zuviel Stasi. Ich denke da wir eh darauf vertrauen (müssen), dass die Leute bezahlen, is ein Bucher überflüssig??? Wenn der Bucher rausfällt, dann fliegt vllt. auch der Kassenwart mit raus, da der ohne den Bucher keine Aufgabe mehr hat. --Jungnickel 09:24, 25. Sep. 2010 (CEST)

Der Kassenwart hat Zugriff aufs Bankkonto der Frunde. Von diesem Konto werden die Getraenke bezahlt. Auf dieses Konto muss irgendwie das bezahlte Geld auch wieder kommen... (darum finde ich seine Rolle wichtig). Bucher hingegen koennte jeder werden. Der Bucher hat aber dafuer zu sorgen, dass nicht zuviel Bargeld in der Frunde herrumliegt. Darum finde ich das Bargeld-aufladen eines frundenkontos in Form direkter Bezahlung an den Bucher schon sinnvoll! --Tkroenert 12:18, 10. Okt. 2010 (CEST)

Okay, klar dafür brauchen wir einen Kassenwart, aber an welcher Stelle der was mit dem System zutun hat hab ich noch nicht geblickt. Zahlung per Überweisung fand ich auch eine interessante Sache. Das Problem mit der Rolle des Buchers ist, dass ich scheinbar nur mein Konto aufladen kann wenn der Bucher da ist. Ich würde da auch vorschlagen: jeder ist Bucher und kann sein Konto aufladen indem er 10€ (oder überweist) in die Kasse wirft und dies in seinem Konto vermerkt. Also eine Rolle Bucher der nur dafür da ist das Geld einzusacken und es auf die unterschiedlichen Konten aufzuladen brauchen wir nicht oder? Dass können die Frundler auch selbst machen. --Jungnickel 13:19, 10. Okt. 2010 (CEST)

Wenn jmd. sein Konto auflaedt, dann wahrschein mit 10EUR oder 20EUR. Wenn nun ein paar Leute mal ihr Konto aufladen liegen schnell 100Euro in der Frunde. Ich sehe das ungern - nicht das ich jmd. der Keymembers nicht vertraue.. es gibt nur momente wo mir viele unbekannte in der Frunde auch mal sind. Und um nun Geld aus der Frunde aufs Konto zu bekommen gibs den Bucher. Jeder koennte das sein.. klar! Aber eben nicht jeder hat die ganzen daten.. also gibs dieses als Rolle. bzw.: Es kann auch mehrere Bucher geben ; ) Und wegen ueberweisen: Das ist natuerlich was anderes!! --Tkroenert 23:54, 15. Okt. 2010 (CEST)

Nur um wirklich letzte Klarheiten auszuräumen: Was unterscheidet den View eines Frundlers von dem eines Buchers am System? Was kann der Bucher mehr als der Frundler (am System)? --Jungnickel 09:54, 16. Okt. 2010 (CEST)

Wenn jetzt JEDER Bucher wäre dann würde diese Klasse doch ad absurdum geführt. Wenn wir den Frundlern nicht vertrauen dann macht das alles keinen Sinn. Warum überweist man nicht "einfach" reales Geld von seinem Realen Konto auf das Reale Konto der frunde? Und trägt das dann selbst ins System ein? Das Bar zahlen kann man ja immernoch nebenher machen. Aber das würde den Bargeld bestand in der Frunde drastisch reduzieren. Dazu kommt die möglichkeit der dauerüberweisung. Natürlich müsste dann ein "Kassenwart" den Geld bestand zwischen Bargeld inner Frunde und Geld eingang aufm Konto überprüfen. Wobei man ja bei der Einzahlung eine $Var nehmen könnte Bar/Überweisung, und das system hält es für den Kassenwart getrennt vor wie viel in der Dose liegen müsste und was aufs Konto gekommen sein müsste.--Timmeey 22:49, 18. Okt. 2010 (CEST)

• Wenn der Gast eine Gast-Karte bekommt (die quasi immer neben dem Scanner liegt), fliegt auch der Gast als Akteur raus, da er dann wie ein Frundler gehandled werden kann. Der Gast bezahlt eh immer in Bar, das wissen wir ja. --Jungnickel 09:34, 25. Sep. 2010 (CEST)

ja, das ist eine gute Loesung! --Tkroenert 23:54, 15. Okt. 2010 (CEST)

Modelle

Objekt: Karte, Konto.
Konto-Aspekte:

• Quota (von -x bis +y)
• Quota ist Attribut eines Kontos (einfacher als nach Kontentypen zu differenzieren)
• immer einer Karte zugeordnet (ist das im Fall des Master-Kontos angemessen?)
• jede Karte kann auf ein zugeordnetes Konto verweisen ("Konsumkonto")
• es gibt Karten die zusätzlich noch ein Bucherkonto haben
• intervall wieviel/welche getränke von letztem Zeitpunkt getrunken wurden angeben

Den letzten Punkt würde ich noch zurückhalten, bis das Getränkeproblem s.w.u. gelöst ist

Subtypen und so

Subtypen von Konto: Kasse, Frundler, Bucher, Gast

Es erscheint am einfachsten, im System nicht weiter zwischen verschiedenen Kontentypen zu differenzieren. Das Quota etwa kann ja ruhig wie oben geschrieben als Attribut am Konto kleben, beim Notifizieren wird uns sicher ähnliches einfallen. Um dennoch für uns zwischen den verschiedenen Zwecken der Konten zu unterscheiden, bekommt jedes Konto noch ein Namensattribut.

Getränke

Hier liegt noch einiges im Argen: Wir wollen mit Sicherheit die verschiedenen verfügbaren Getränketypen (Mate, Cola, ...) in einer Tabelle speichern, und daraus u.A. das manuelle Getränkemenü zu generieren etc. Da steht dann auch der Preis dran. Dann gibt es zwei Möglichkeiten:

• keine abgeschlossene Transaktion verweist auf ein solches Getränk (sonst ändert sich die Transaktion, wenn das Getränk einen anderen "Preis" bekommt)
• wenn wir den "Preis" für Mate erhöhen, legen wir mehrere Mate-Einträge an, einmal mit altem Preis, einmal mit neuem, und konsumieren kann man nur nach aktuellem Preis, die alte erscheint nicht im Menü

Beides ist irgendwie häßlich. Vorschläge?

• Warum nicht den Preis beim Erstellen der Transaktion ins Transaktionsobjekt kopieren?
• Getränkeobjekte und Preisobjekte getrennt anlegen. Preise sind einem Getränkeobjekt zugeordnet und haben nebem einem Preis ein Startdatum. Somit können alle Preisänderungen problemlos nachvollzogen werden und nichts wird redundant gespeichert. So habe ich das bei meiner Getränkekasse gelöst. (externer Kommentar von tblank@gmx.net)

weitere Aspekte

Logging

• Jede Transaktion, wer von wo nach wo wie viel und wann und aus welchem Anlass erscheint im System. (auch wenn welches Getränk)
  • Bitte versuchen das Prinzip der Datensparksamkeit nicht zu vergessen. Daten die nicht gespeichert sind können auch nicht wegkommen --Bmay 19:48, 10. Okt. 2010 (CEST)
• Löschen von Transaktionen solange sie noch nicht commited ist (Session nicht vorbei) ist möglich
• Wie sieht ein Commit in der Logik aus?
• Sonstige Löschvorgänge von Transaktionen ist nicht möglich
  • Ich nehme an, damit ist das Löschen durch den Nutzer selbst gemeint. Ein "Storno" sollte zumindest der Admin und ggF. der Bucher können um Irrtümer zu korrigieren, für Testzwecke, etc. --Bmay 19:48, 10. Okt. 2010 (CEST)

Loeschmoeglichkeit der in den letzten n Minuten getaetigten Buchungsvorgaenge wuerde alle Probleme loesen.. --Tkroenert 23:54, 15. Okt. 2010 (CEST)

• Frundler kann seine kürzlich gekauften Getränke einsehen.

History ueber getaetigte Buchungen... --Tkroenert 23:54, 15. Okt. 2010 (CEST)

• • Auch hier wieder, Datensparksamkeit. Eine Möglichkeit zum Abruf eines digitalen Kontoauszugs wäre gut - danach kann die entsprechende Liste wieder gelöscht oder zumindest verschlüsselt zum Backup abgespeichert werden. --Bmay 19:48, 10. Okt. 2010 (CEST)

Notification

• Kassenwart muss über Geldübergabe an Bucher benachrichtigt werden
  • Eventuell lässt sich hier eine Mail, Jabber, Statusneet, whatever Lösung basteln --Bmay 19:48, 10. Okt. 2010 (CEST)
• Bei MaxBetrag in Kasse muessen die Bucher benachrichtigt werden