Kassensystem

2010-10-18T20:46:52Z

92.225.98.158: /* Rollen */

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.

=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 --[[Benutzer:Jörg F|Jörg F]] 10:47, 26. Sep. 2010 (CEST)
*** leider läuft der Touch nur unter nem extrem alten X --[[Benutzer:Jungnickel|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. --[[Benutzer:Mutax|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 --[[Benutzer:Andrew|Andy[DE]]]
** für jeden zugänglich --[[Benutzer:Jörg F|Jörg F]] 10:47, 26. Sep. 2010 (CEST)
** Leichter Zugang für Gäste und schnelle Mate trinker/käufer --[[Benutzer:Jungnickel|Jungnickel]] 10:57, 26. Sep. 2010 (CEST)
* Browser
** man muss nen Laptop mit Internet dabei haben --[[Benutzer:Jörg F|Jörg F]] 10:47, 26. Sep. 2010 (CEST)
** es können parallel Getränke gekauft werden --[[Benutzer:Jungnickel|Jungnickel]] 10:57, 26. Sep. 2010 (CEST)
** den Verbrauch und Kontostand sollte einsehbar sein ohne an den Touchscreen zu gehen. --[[Benutzer:Jungnickel|Jungnickel]] 10:57, 26. Sep. 2010 (CEST)
** Komplexere Seiten (Geld aufladen etc) sind vllt. leichter für den Browser zu implementieren--[[Benutzer:Jungnickel|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)''

# Frundler konsumiert:
## Der Frundler authentifiziert sich am System
## Der Frundler sagt dem System er kauft ein Getränk
## Das System belastet das Konto des Frundlers mit dem genommenen Getränk
# Gast konsumiert:
## Der Gast sagt dem System er kauft ein Getränk.
## Der Gast legt den zum Getränk passenden Betrag in die Barkasse
## Der Gast nimmt sich das Getränk
# Bucher laedt Frundlerkonto auf
## Der Frundler gibt dem Bucher $Geld Euro
## Der Bucher authentifiziert sich am System
## Er hebt den Betrag vom Buchungskonto ab
## Er laedt das Geld auf das Frundlerkonto
# Bucher leeren Kasse
## Der Bucher authentifiziert sich am System
## Der Bucher nimmt das Geld aus der Barkasse
## Der Bucher bucht das Geld vom Barkassenkonto auf sein Konto
# Bucher gibt Geld an Kassenwart weiter
## Der Bucher gibt dem Kassenwart (auch per Banktransfer) das gewartete Geld
## Der Kassenwart authentifiziert sich am System
## 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. --[[Benutzer:Jungnickel|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! --[[Benutzer:Tkroenert|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. --[[Benutzer:Jungnickel|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!! --[[Benutzer:Tkroenert|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)? --[[Benutzer:Jungnickel|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.
* 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. --[[Benutzer:Jungnickel|Jungnickel]] 09:34, 25. Sep. 2010 (CEST)
:: ja, das ist eine gute Loesung! --[[Benutzer:Tkroenert|Tkroenert]] 23:54, 15. Okt. 2010 (CEST)

=Modelle=
Objekt: Karte, Konto.<br />
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 --[[Benutzer:Bmay|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. --[[Benutzer:Bmay|Bmay]] 19:48, 10. Okt. 2010 (CEST)
:: Loeschmoeglichkeit der in den letzten n Minuten getaetigten Buchungsvorgaenge wuerde alle Probleme loesen.. --[[Benutzer:Tkroenert|Tkroenert]] 23:54, 15. Okt. 2010 (CEST)
* Frundler kann seine kürzlich gekauften Getränke einsehen.
:: History ueber getaetigte Buchungen... --[[Benutzer:Tkroenert|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. --[[Benutzer:Bmay|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 --[[Benutzer:Bmay|Bmay]] 19:48, 10. Okt. 2010 (CEST)
* Bei MaxBetrag in Kasse muessen die Bucher benachrichtigt werden

FreitagsrundenWiki - Benutzerbeiträge [de]

Kassensystem