Bedienoberfläche für eine Kasse / Denkanstöße

  • VB.NET
  • .NET (FX) 4.0

Es gibt 21 Antworten in diesem Thema. Der letzte Beitrag () ist von frifri.

    Bedienoberfläche für eine Kasse / Denkanstöße

    Hallo,

    ich möchte mir ein Kassensystem erstellen. Nun geht es um die Bedienoberfläche. Es soll mit Touchscreen bedient werden.
    Es werden 25 (5 Reihen 5 Zeilen) Schnelldreher Tasten erstellt werden. Das ganze mit mehreren Unterseiten.

    Ich stelle es mir so vor:
    in der obersten Reihe stehen die Gruppen ( ich nehme jetzt mal ein Beispiel aus dem Getränkemarkt, kennt wohl jeder)

    Also erste Gruppe Getränke - zweite Gruppe Weine - dritte Gruppe Spirituosen - vierte Gruppe Sonstiges
    In der zweiten Reihe stehen die Untergruppen:

    Betätige ich den Button für Getränke ändern sich die Buttons für Untergruppen in z.B. Bier, Wasser, Cola, usw.
    Betätige ich den Button für Weine ändern sich die Buttons für die Untergruppen in Franzosen, Italiener, usw.

    Betätige ich erst den Button für Getränke und dann den Button für Wasser sollen da die ganzen Wassersorten erscheinen.

    Die eigentlichen schnelldreher Tasten ändern natürlich auch jedes mal ihre Beschriftung
    des weiteren sollten für die eigentlichen Schnelldreher Tasten eine zweite evtl. auch eine dritte Seite erstellt werden können / könnten ja mehr Sorten Bier auf den Tasten liegen sollen als nur die 25.

    Jetzt meine eigentliche Frage:

    Wie sollte ich die Oberfläche erstellen?

    Sollte ich 25 Buttons und je 5 Buttons für die Gruppen und Untergruppen und je zwei Tasten um die Seite weiter "umzublättern" , einfach als Oberfläche anlegen und diese immer ( wie auch immer das gehen soll ) neu füllen wenn einer der Gruppen bzw. Untergruppen Buttons gedrückt wird.
    oder
    kann man so was irgendwie mit einem Menü mit Reitern erstellen und so hintereinander anordnen. Es sollten ja auch die Seiten mit den Schnelldreher Tasten noch umgeblättert (nicht gescrollt) werden können.
    Das Umschalten zwischen den einzelnen Ebenen darf ja nicht lange dauern, ist ja eine Kasse , muss ja schnell gehen.
    Die Reiter dürfen ja auch nicht zu klein sein, es muss ja mit dem Finger bedient werden können.

    Auf der Oberfläche müssten ja 5 * 5 * 25 * 3 = 1875 Artikel angesprochen werden können. Und jeder Artikel hat ja einen Preis, einen Namen, einen MwSt Satz und eine ArtikelNr die müssten ja auch mit abgelegt werden 1875 * 4 = 7500 Variablen.
    Die Daten für Preis, Name, MwSt Satz, und Nummer erst beim drücken der Taste aus einer Datenbank zu suchen könnte evtl. zu lange dauern und das hält beim kassieren zu sehr auf wenn das Programm erst immer eine "Gedenkminute" braucht bevor der Artikel eingegeben ist.


    Ich brauche halt ein paar Denkansätze, Tips, Ideen.

    danke

    frifri schrieb:

    Ich brauche halt ein paar Denkansätze, Tips, Ideen.

    Kauf Dir eine Kassensoftware.
    Es gibt davon Unmengen und davon einige sehr gute Versionen.
    Bis Du so weit bist, dass Deine eigene Version einigermaßen funktioniert, hast Du wertvolle Lebenszeit verloren.
    Warum ich das so sage? Aus Deiner Fragestellung kann ich entnehmen, dass Du enorme Schwierigkeiten haben wirst, es gut umzusetzen.

    frifri schrieb:


    Sollte ich 25 Buttons und je 5 Buttons für die Gruppen und Untergruppen und je zwei Tasten um die Seite weiter "umzublättern" , einfach als Oberfläche anlegen und diese immer ( wie auch immer das gehen soll ) neu füllen wenn einer der Gruppen bzw. Untergruppen Buttons gedrückt wird.
    ....
    Ich brauche halt ein paar Denkansätze, Tips, Ideen.

    Egal wie du es letztendlich machen wirst.
    Aber ich würde gänzlich auf Buttons verzichten, sondern praktisch alles auf einem selbst "gemaltem" control zaubern, denn du wirst schnell merken, wie oft du das Layout ändern musst/willst.
    Und da sind Buttons samt Events extrem hinderlich.
    Auch bist du so freier in der Gestaltung der Größe, Form und Farbe, die du dann wenn man es ganz extrem mag sogar dem Lagerbestand in Realtime anpassen kannst.
    Also schön flexibel halten, so kannst du schnell und einfach reagieren, wenn sich das Layout doch ändern sollte.

    und punkto Layout..
    Betreibe "Jugend forscht" und geh mal in den ein oder anderen Laden und schau dir dort die Displays an.
    Etwas "Inspiration" bei der Konkurrenz holen hat noch nie geschadet :)

    in vier Views-Videos ist ein Rundumschlag, was so die Standard-Präsentationsformen sind.

    In DataExpressions ist ein Winz-Kassenprogramm drinne "MiniKass".

    Ich würd empfehlen, zunächstmal mit ganz drögen Elementen und möglichst wenig Gui-Aufwand vorrangig erstmal die Logik klarzukriegen, dass stabil läuft.
    Schnelldrehertasten mit Gruppen und Seiten und unterseiten und Touchscreen und Krims und Krams...

    Mach das, wenn die Funktionalität funktioniert.

    RoulettePilot schrieb:

    Aber ich würde gänzlich auf Buttons verzichten, sondern praktisch alles auf einem selbst "gemaltem" control zaubern, denn du wirst schnell merken, wie oft du das Layout ändern musst/willst.


    Ich hab mich mit Controls noch nicht beschäftigt - hol ich aber nun nach :)

    Kann man denn mit nur einem Controll verschiedene Ereignisse auslösen?

    frifri schrieb:


    Kann man denn mit nur einem Controll verschiedene Ereignisse auslösen?


    Die kannst dies z.B. mit dem MouseClick-Event abfragen. Diese gibt die X-Y-Coordinate zurück, so das du im einfachsten Fall abfragen kannst, wo der Klick stattfand.
    und im Paintevent einfach die Buttons "malen" :)

    Zum Test ein neues "Benutzersteuerelement" hinzufügen.. auf deine Form ziehen... und los geht's :)

    Hier mal ein Simples Beispiel, das die "grobe" Vorgehensweise von meiner Warte aus aufzeigt,
    Spoiler anzeigen

    VB.NET-Quellcode

    1. Dim myButtons(-1) As Rectangle ' erstmal "leer" erstellen
    3. ' z.B in der New Routine deiner From die Buttons mit "Leben" füllen
    4. Public Sub New()
    5. ' Dieser Aufruf ist für den Designer erforderlich.
    6. InitializeComponent()
    7. ' Fügen Sie Initialisierungen nach dem InitializeComponent()-Aufruf hinzu.
    8. ' hier z.B. in der Form 3 Buttons in Position und Größe festlegen
    9. ReDim myButtons(2)
    10. myButtons(0) = New Rectangle(10, 20, 40, 40)
    11. myButtons(1) = New Rectangle(80, 20, 40, 40)
    12. myButtons(2) = New Rectangle(150, 20, 40, 40)
    13. End Sub
    15. ' hier die Buttons zeichnen
    16. Private Sub UserControl11_Paint(sender As Object, e As PaintEventArgs) Handles UserControl11.Paint
    17. For i = 0 To myButtons.Length - 1
    18. e.Graphics.DrawRectangle(Pens.Black, myButtons(i))
    19. Next
    20. End Sub
    23. ' hier abfragen welches Button geklickt wurde
    24. Private Sub UserControl11_MouseClick(sender As Object, e As MouseEventArgs) Handles UserControl11.MouseClick
    25. For i = 0 To myButtons.Length - 1
    26. If myButtons(i).Contains(e.Location) Then
    27. MsgBox("Button " & i & " gedrückt")
    28. Exit For
    29. End If
    30. Next
    31. End Sub




    Du siehst, sooo schwer ist es nicht.. nur halt noch ein wenig "hübscher" machen, Structuren für die Buttons verwenden und und und...

    ich sags noch einmal, dann lass ich euch weiter ungestört auf euerm Holzweg:
    Die Entwicklung der Oberfläche einer Datenverarbeitung kann man erst in Angriff nehmen, wenn die Funktionalität steht.
    Also erst das Datenmodell machen, dann Primitiv-Gui draufsetzen, um die Funktionalität zu testen.
    Dann die Oberfläche gestalten dass es nur so kracht.

    Was ihr da derzeit treibt ist wie totschicke Sachen einkaufen ohne anzuprobieren. Und so endet das auch: Ihr werdet sie nämlich komplett wegschmeißen.

    ErfinderDesRades schrieb:

    ...Ihr werdet sie nämlich komplett wegschmeißen.

    .. und dabei gelernt haben, das man, wenn man 50 Buttons irgendwo braucht, man keine 50 Buttons als einzelne Controls einfügen und abfragen muss, sondern man das recht simpel mit einem erledigen kann,
    welches dann noch recht flexibel ist.

    .. wenn das nichts ist :)

    Immerhin bezog sich die Antwort auf "Kann man denn mit nur einem Controll verschiedene Ereignisse auslösen?"

    Die Frage ergibt in meinen Augen gar keinen Sinn. Sie deutet nur darauf, dass weder Editor noch Form-Designer in ihren Funktionen hinlänglich bekannt sind - ganz zu schweigen vom ObjectBrowser:


    @frifri: Also, was meinst du:
    "Kann man denn mit nur einem Controll verschiedene Ereignisse auslösen?"


    (Im übrigen scheinen dir so viele Grundlagen zu fehlen, dass ein kluges Buch zumindest parallel zu lesen dein Projekt am schnellsten voran bringen wird: dieses Buch lesen (hingegen das Galileio-Openbook ist Mist))

    man kann es auch falsch verstehen "wollen".
    Im Zusammenhang wurde ehr gemeint, verschiedene "Click-Ereignisse"-Ereignisse .. also das man unterscheiden kann, welcher Button geklickt wurde..
    Den ganzen anderen Kladdaradatsch .. danach wurde nicht gefragt.

    Hmm?
    lies die Frage - da steht doch, wonach gefragt wurde.

    Für den Fragesteller denken, was er wohl gemeint haben könnte, ist meist so oder so ein Bärendienst:
    Liegt man falsch, so hat man eine wunderbare Grundlage für die dollsten Missverständnisse gelegt.
    Liegt man richtig, so hat man den Fragesteller immer noch ein Stück entmündigt, statt ihm zu helfen sein Problem zu formulieren, und auf diese Weise klar zu kriegen.

    Ich weiß ja nicht, ob das nur eine Übung ist oder ob das auch in der Praxis eingesetzt werden soll.
    Falls wir vom zweiten Fall ausgehen:

    Eine Kassensoftware ist eine Echtzeitanwendung.
    Klare Priorität hat hier das Abarbeiten der Klick-Events.
    Zweite Priorität hat der Datenzugriff. Spätestens beim Enter, also beim Einbuchen des Artikels , müssen die Artikeldaten verfügbar sein.
    Das Aktualisieren der Oberfläche ist nachrangig und kann im Hintergrund erfolgen und muss keineswegs abgeschlossen sein, wenn der nächste Klick erfolgt, der die Oberfläche schon wieder komplett verändert.

    Im Klick-Event wird nur der neue Status gesetzt, der im Buchungsfall den Pointer auf den Artikel setzt.

    Das nachrangige Abarbeiten der Anzeige sollte trotzdem noch schnell genug gehen, dass keine optische Irritation entsteht, falls der Bediener doch mal auf die Oberfläche schaut.
    Deswegen die Daten im RAM halten und nicht erst lange von der Platte nachladen.

    Hilfreich ist auch eine akustische Rückmeldung beim Klick.

    Und wenn du noch eine Barcode-Schnittstelle vorsiehst, kannst du fast schon produktiv werden.
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „petaod“ ()

    petaod schrieb:


    Das nachrangige Abarbeiten der Anzeige sollte trotzdem noch schnell genug gehen, dass keine optische Irritation entsteht, falls der Bediener doch mal auf die Oberfläche schaut.
    Deswegen die Daten im RAM halten und nicht erst lange von der Platte nachladen.

    So schnell kann keine Aldi-Kassiererin tippen, als das es auch nur Ansatzweise zu "Irritationen" kommt. :P

    Auch wenn das Teil nie zum Einsatz kommt. Es ist ein "Ding" an dem man sich wunderbar hochlernen kann.
    Alles was hier genutzt oder "gebaut" wird, wird sich später sicher in anderen Projekten wiederfinden.
    So lernt man doch am Besten. Ein interessantes Teil suchen, loslegen und dann Stück für Stück die Steine aus dem Weg legen.

    Der Weg ist das Ziel :) :) :)

    RoulettePilot schrieb:

    wenn das Teil nie zum Einsatz kommt
    ist das alles kein Problem.
    Wenn es zu Übungszwecken geschrieben wird, funktioniert jeder Ansatz.

    RoulettePilot schrieb:

    Es ist ein "Ding" an dem man sich wunderbar hochlernen kann.
    Man könnte dabei auch lernen, wie man Echtzeitsoftware schreibt,
    --
    If Not Program.isWorking Then Code.Debug Else Code.DoNotTouch
    --

    petaod schrieb:

    Man könnte dabei auch lernen, wie man Echtzeitsoftware schreibt,

    nicht nur das, auch wie man .. gerade wie man bei solch sensiblen Kassen-Daten "sicher" programmiert,
    also das auch bei Stomausfall usw. keine "Transaktionen" verloren gehen...

    und und und...

    mir fallen da 1000 Dinge ein, das ich aufpassen muss, nicht gleich selbst so nen Teil zu schreiben.. he he

    (Aber bei mir wäre sowas nie fertig, da ich immer wieder was finde, was man noch besser machen könnte... wäre eine ewige Baustelle... aber... eine interessante) *g*

    Ich wollte doch nur ein paar Denkanstöße. Ein Paar Ideen in welche Richtung ich mich bewegen sollte und zwar bevor ich irgendwas anfange.
    Das mit dem Benutzersteuerelement ist doch ein sehr guter Ansatz. Das heißt doch nicht das ich das jetzt sofort in Angriff nehme.

    Wenn ich Klamotten kaufen gehen möchte, um mal bei deinem Beispiel zu bleiben, und frage wo kann ich denn was einkaufen und da schreit einer sofort "Spar doch erst mal das Geld zusammen bevor du mit solchen Fragen daher kommst", heißt es doch nicht das ich sofort losrenne. ich mache mir halt schon mal Gedanken in welche Richtung ich gehen möchte oder was es sonst noch für Ideen gibt so etwas umzusetzen.
    Ideensammeln oder Neudeutsch Brainstorming.
    Soll ich alles fertig machen und dann erst fragen wie hättet Ihr das gemacht.

    Du machst halt erst den Unterbau und ich mach mir auch schon mal Gedanken wie das der Endanwender bedienen kann.
    Wenn ich manche Programme so sehe hätten das viele Profi Programmierer auch mal lieber getan. Ich hab schon an Kassen gearbeitet das war eine tägliche Qual.
    Klar geht das irgendwie.
    Wenn Programmierer Autos entwickeln würden hätte eins bestimmt das Zündschloss im Kofferraum. Wieso geht doch. Ist aber nicht praktikabel.
    Kann man dem Programmierer eigentlich auch keinen Vorwurf machen, der hat ja auch noch nie an einer Kasse gearbeitet, viele wahrscheinlich noch nicht mal selbst eingekauft :)
    aber die hätten halt jemanden fragen sollen der sich mit so was auskennt.

    Und darum sammele ich "jetzt schon" Ideen.

Facebook
Telefonspende