Artikeltasten Datenmodel->Darstellung

  • VB.NET

Es gibt 6 Antworten in diesem Thema. Der letzte Beitrag () ist von Tigerente.

    Artikeltasten Datenmodel->Darstellung

    Hallo zusammen,

    habe lange schon keine Hilfe mehr benötigt, aber jetzt fehlt mir 'nen bissl die Idee für den Start. Scenario:
    Ich habe ein Kassendisplay in einem Supermarkt. Dort sollen Warengruppen->Untergruppen->Artikeltasten dargestellt werden, einer Hierarchie folgend z.B.:
    Reinigungsmittel->Bio->Essig
    Reinigungsmittel->Bio->Orangensaft
    Reinigungsmittel->wirksam->giftig->Salzsäure
    Reinigungsmittel->wirksam->giftig->Salpetersäure
    Reinigungsmittel->wirksam->ungiftig->grün->Hafermilch
    ...
    Der User drückt also auf den Button Reinigungsmittel, bekommt dann 2 Button (Bio, wirksam zur Auswahl), nach Button Bio gibt es die Produkte Essig und Orangensaft zur Auswahl.

    Die Idee: Ich habe ein typ. Dataset mit n.Tabellen, die jeweils eine Spalte (Parent_Key) haben und auf die nächsthöhere Ebene verweisen. Das funktioniert soweit auch.
    Mein Problem: Ich muss das irgendwie graphisch darstellen(das geht ja noch) und im Backend eine Pflegemöglichkeit zur Verfügung stellen.

    Ein dgv würde sich zwar bezüglich einfügen, löschen, verschieben(per D&D) u.s.w. anbieten, bringt aber auf Grund der Darstellung (2-3 Texte und ein Bild pro Taste) einige Probleme.
    Außerdem haben wir hier ja eine Row pro DS und ich brauche ja eine Zelle/DS´(was natürlich auch lösbar ist)

    Ich könnte mir vorstellen, dass jemand schonmal eine ähnliche Aufgabenstellung hatte und mir einen Ansatz geben kann.
    Manchmal ist man einfach blind...

    Du sprichst von Warengruppen, ja, da könnte man sich einen Daten-Baum zu vorstellen.
    Also jedes Produkt kann nur in einer Gruppe sein, und jede Gruppe hat nur eine übergeordnete Gruppe usw.

    Aber deine Beispiele scheinen keine Warengruppen, sondern Kategorien zu sein.
    Bei Kategorien kann jedes Produkt mehrere Kategorien aufweisen.
    Etwa Essig kann Bio und wirksam sein.

    Das würde ein anderes Datenmodell erfordern und auch ein anderes GUI.

    Also erste Frage: Ist der Warenbestand wirklich in einem Baumartigen Datenmodell korrekt abgebildet?
    Ehrliche Antwort, weil wenn nicht, kann bei deim Ansatz nur Murx bei rauskommen.


    Ansonsten ein "Button-GUI" für baumartige Daten könnte man in zwei FlowlayoutPanels umsetzen: Das erste flp geht quasi von Gruppe zu Untergruppe in die Tiefe des Baumes, das zweite flp zeigt die jeweiligen Elemente der aktuell untersten Gruppe an (also die Breite, wenn man so will)

    Ist auf jeden Fall ziemlich begrenzt: Wenn du mehr als 15 buttons in einem flp hast wird das unübersichtlich, und du musst scrollen (was auffm Touch glaub problematisch ist)

    Eine Idee zum Fall Kategorien
    Bei Tastendruck auf eine Kategorie ein Kennzeichen setzen. Am Ende haste dann einen Integer der alle Kategorien identifiziert. (Wie Flags Enum)
    Da wäre eine Produkttabelle schon ausreichend.

    Produkte, Kennzeichen
    Salzsäure, 21
    Salpetersäure, 23
    Essig, 65

    Reinigungsmittel->unwirksam->giftig
    bit1->bit4->bit16 = 10101_bin = 21_dec

    Da wird dann 21 und 23 mit gefunden, weil dieselben bits gesetzt sind wie in deinem Such-Integer.
    Bei nur Reinigungsmittel taucht Essig auch noch auf, weil dann der Such-Integer nur bit1 gesetzt hat.

    Bedenke aber, dass sich nicht jeder Anwender/Unternehmer mit der "nicht vorhandenen Sortierung" der Artikeltasten zufrieden geben wird.
    Manchmal möchte man ja oft genutzte Artikeltasten schneller aufrufbar haben.

    Ich empfehle (so mache ich es zumindest seit 20 Jahren): Trenne Oberfläche von den Daten.
    Lass den Kunden die Oberfläche selbst gestalten.

    Ich bin sogar so weit gegangen, dass jede Taste nicht nur ein Artikel sein kann, sondern auch ein grafisches Element, eine Zahlart oder eine beliebige Programmfunktion.
    So kann sich jeder selbst seine Oberfläche individuell gestalten. Die Informationen (Tasten <> Artikelnummer) ist in einer separaten Datenbank gespeichert.
    Über die Tasten kann ich auch die verkaufte Menge steuern. Die Texte auf den Tasten können andere sein als beim Artikel (oft ist der Artikeltext sehr lang, aber man kann es auf der Taste abkürzen).

    Aber mit "meiner" Methode stößt man natürlich an Grenzen, wenn es viele Artikel sind.
    Unsere Kunden haben meist zwischen 50 und 600 Artikel.

    Vielleicht hier ein paar Ideen (Screenshots einer meiner Anwendungen):
    Bilder

    • BFP_Screenshots_BuchenOhneRahmen.jpg

      302,94 kB, 1.440×900, 49 mal angesehen

    • BFP_Touchtasten1.jpg

      437,77 kB, 1.027×774, 53 mal angesehen
    Liebe Grüße
    Roland Berghöfer

    Meine aktuellen und kostenlos verwendbaren Tools (mit VB.NET erstellt): freeremarkabletools.com | priconman.com | SimpleCalendar | AudibleTouch | BOComponent.com | bonit.at

    Also erstmal danke, für die schnellen Antworten.
    Es ist tatsächlich so, dass eine Kategorie an mehreren Zweigen hängen kann. Ebenso auch die Produkte.
    Erschwerend kommt hinzu, dass die Produkte nicht zwingend das Ende des "Baums" sein müssen. Es kann Kategorien geben, die direkt Produkte enthalten (z.B. häufig verwendete Topprodukte) und trotzdem noch Unterkategorien haben.

    Und ja, es gibt keine Begrenzung der Elemente im Screen - im Zweifelsfall muss der Anwender halt scrollen.

    Noch eine Info: Mein Part ist "nur" Entwicklung der GUI für einen PC, wo die Hierarchie gepflegt wird. Ich sende dann die finale Struktur per JSON zur API der Kasse.
    Ich hoffe, ich habe es ausreichend detailliert beschrieben, ansonsten fragt gern nochmal nach.

    Mach doch mal eine kleine Datensammlung (20 Produkte) und probier die Ansätze aus.
    Welcher gut ist kann nämlich von Fall zu Fall unterschiedlich sein. Sowas wie "häufig verwendete Topprodukte" ist etwas, was nicht ins Kennzeichenbild passt, das verändert sich ja dauernd.
    Das lässt sich aber auch nicht so schön mit Gruppen lösen, dafür wirst du vermutlich noch was extra brauchen.
    Eine Eigenschaft "Anzahl verkauft im letzten Monat"?
    Allerdings müsste der Kassierer, das ja wissen, sonst weiß er gar nicht wann dieser Knopf ihm hilft und wann nicht.

Facebook
Telefonspende