Kassensystem

Aus RaumZeitLabor Wiki
Wechseln zu: Navigation, Suche
     
Kassensystem

Release status: experimental [box doku]

Kpos webinterface draft.png
Description Kassensystem mit Barcode-Scanner und Webinterface zur Verwaltung
Author(s)  echox, eeemsi, else, hax404, muzy, nazco, xandy
Last Version  yet to be released
Cashpoint-Manager

Ideen

  • "normale" Hardware (Thin Client? siehe z.B. hier oder hier)
    • Booten von Compact Flash oder USB Stick
    • Anbindung an User Datenbank über Netzwerk (Kabel in der Küche?)
    • Warenwirtschaftssystem "light"
  • Scannen von Artikeln mittels Barcodescanner (EAN8 / EAN13 Code)
  • Gerät bietet keine "Mehrwertdienste" und ist nur eine dumme Kasse (;_;)
  • Ausgabe erfolgt über Monitor bzw. 4x20 oder 4x40 Zeilendisplay (DaFo)
  • Identifizierung bzw. Autorisierung über persönlichen Code
    • Frage: gleicher Code wie Tür oder separat?
    • Mitgliedskarte mit Barcode?
    • wenn Karte vergessen, Eingabe des Codes über Pinpad
  • zwei Arten von Kunden: Gäste bzw. Mitglieder
    • Guthabenkarte für Gäste, aufgeladen mit bestimmtem Betrag (nicht personengebunden)
    • Guthabenkarte für Mitglieder, kann beliebig aufgeladen werden (personengebunden)
    • eventuell andere Preise für Gäste
  • evtl. später: Einzahlen mittels Geldleser
  • "Trusted Persons" zwecks Einzahlung
  • bei Zahlungsvorgang: Geräusch (Instantsfun!!!11)
  • Zugriff aufs Kassensystem nur ausgewählte Personen
  • Systemlogging auf Server für Monitoring
    • Papertrail für alle Transaktionen
  • lokale Datenbank mit regelmäßigem Backup
  • Preisverwaltung über Webinterface
    • Authentifizierung gegen Mitgliedsdatenbank
    • "normale" Benutzer können Einkaufshistorie einsehen (falls aktiviert)

Prozess "Bezahlen"

  1. Identifierung der Person
    verfügbares Guthaben wird angezeigt
  2. Artikel scannen
    jeder gescannte Artikel wird bereits gegen Guthaben geprüft (bei Fehlbetrag Warngeräusch)
  3. Bestätigung bzw. Abbruch der Transaktion
    Verbuchung des Vorgangs & Verrechnung mit Konto
  4.  ???
  5. Profit

Prozess "Aufladen"

Generell gilt: nur im Voraus!

  • per Überweisung aufs Konto vom RaumZeitLabor (Verwaltungsaufwand? eventuell HCBI) oder
  • bar bei ausgewählten "Trusted Persons" (Bestimmung über Plenum/Mitgliedsversammlung?)

Reporting

  • Umsatz pro Gruppe, Produkt, User (nur falls gewünscht) pro Zeiteinheit
  • Produkte, deren Lagerbestand unter Schwellenmenge ist
  • Aufteilung des Produktmixes nach Umsatz / Gewinn
  • Produkte mit baldigem Verfall
  • Gewinn

Architektur

+--------------+  HTTP  +--------+  HTTP  +-----------------+
|Kassenterminal| <----> |Core-API| <----> |Verwaltungssystem|
+--------------+        +--------+        +-----------------+
       ^                     ^                     ^
  CP-Terminal             CP-API               CP-Manager
  • Core API: REST & JSON
    • stellt Funktionen der Kasse bereit (inkl. Administration)
    • Slim sieht perfekt für unsere Zwecke aus
    • Doctrine2 als ORM
  • Kassenterminal
    • 4x40 Zeilendisplay
  • Verwaltungssystem
    • Webanwendung

Cashpoint-Manager

  • Android-Anwendung zur Verwaltung des Cashpoints

Datenmodell

Achtung, die folgenden Angaben können abweichen!

  • Produkt: PID, EAN, Name, MengenEinheit, SchwellenMenge, DatumAufgenommen
  • Einkauf: EID, PID, UID, Lieferant, DatumEinkauf, VerfallsDatum, Menge, EKPreis
    • EKPreis wird als Basis für Berechnung der Standardkondition herangezogen
    • Überlegung, ob FIFO (vermutlich), LIFO oder Durchschnitt genommen werden soll
  • Kondition: KID, GID, UID, PID, Menge, Aufschlag, Abgabe, Kommentar, DatumStart, DatumEnde
    • ermöglicht granulare Preissteuerung bis auf den Käufer (z.B. bei Geburtstag)
    • jede Gruppe sollte einen GID Eintrag haben (ohne UID und PID) mit Standardfaktor (vom EK)
    • drei Konditionsarten möglich: Aufschlag, (Fix-)Preis, und Aufschlag mit Abgabe (z.B. für Pfand)
    • DatumEnde muss nicht gesetzt sein (unbegrenzt)
  • PreisCache: PCID, KID, Preis
    • muss bei Erstellung von Konditionen sowie Einkäufen aktualisiert/generiert werden
  • Verkauf: VID, GID, UID, DatumKauf, Total
    • UID ist nur auf Wunsch gesetzt, um Historie einsehen zu können
  • VerkaufsPosition: PosID, VID, KID, PID, Menge, Summe
  • GuthabenKarten: GKID, Code, GID, UID, DatumAusgestellt
    • wenn UID Null, dann anonyme Cashcard (z.B. für Gäste)
    • wenn UID Null, dann muss GID gesetzt sein
  • Guthaben: CID, GKID, VID, AufladungsArt, Anmerkung, Datum, Betrag
    • VID kann leer gelassen werden (bei Aufladung)
    • AufladungsArt ist z.B. bar, Überweisung, ...
    • Anmerkung je nach AufladungsArt (z.B. verantwortliche Person, Transaktionscode)

Aktueller Stand

  • Futro S300 mit 1GHz (danke Felicitus)
    • MAC: 00:90:dc:a1:0f:93
  • PSC QS6000+ Barcode Scanner (Übersicht, Handbuch)
  • 2GB CompactFlash Karte (danke docsteel)
    • alternativ: 2.5GB "Microdrive" (von Seagate)
  • Debian 6.0.1a testweise installiert (eine Partition, ext4)
    • idealerweise in Zukunft als Image, was in RAM entpackt wird
    • Zugriff über SSH
  • 4x40 Zeilen LCD mit HD44780 Controller

Code

Links