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.

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

weiche Anforderungen

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

• 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
• ...

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)
  • 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)

• 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)

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 wieviel und wann und aus welchem Anlass erscheint im System. (auch wenn welches getränk)
• löschen von transaktionen solange 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
• Frundler kann seine kürzlich gekauften Getränke einsehen.

Notification

• Kassenwart muss über Geldübergabe an Bucher benachrichtigt
• Bei MaxBetrag in Kasse muss der Kassenwart benachrichtigt werden