nicht angemeldet
Hallo Vinzenz,
erstmal danke für Deine Beteiligung.
Es ist eine sehr schlechte Idee, für einen Preis *Float* zu verwenden. Dafür gibts DECIMAL() und Konsorten. Ein wunderbarer exakter Datentyp, mit dem sich wunderbar rechnen läßt.
Sorry, natürlich nehme ich DECIMAL (6,2) als Datentyp. Meine Funktion, die den Datentyp vor dem Eintrag auf ihren Kontext hin überprüft, hat den Parameter *float*, daher die Verwechslung.
Ich kann mir nicht vorstellen, dass einem Benutzer Szenariennummern etwas sagen. Er kann sich sie also auch nicht merken und wird sie nicht eingeben.
Genau so sehe ich das auch.
Insgesamt sieht es mir nach einer typischen Warenkorb-Anwendung aus - mit einem Warenkorb fest vorgegebener Größe.
Ok. Der Einfachheit halber nehmen wir das ab jetzt an. Es geht also um einen Warenkorb, den der User anlegt und mit dem infolge des Requests "was auch immer" passiert.
Im Frontend hat der User ein Formular, in den er (Beispiel Warenkorb) die Artikelnummer, die Bezeichnung, und 2-3 weitere Felder eintragen kann. In diesem Beispiel natürlich sinnvollerweise nicht den Preis ;-)
Bei diesem Formular würde ich (und muß ich auch, wegen der verbleibenden 10% Freieinträge) schon ganz gerne bleiben. Also benötige ich für den User eine Art Eingabehilfe, um das Formular auszufüllen, da er ja meine Produktpalette nicht auswenig kennt. Er sollte also eine Suchfunktion zur Verfügung haben, in das er die Bezeichnung oder die Artikelnummer eintragen kann und das ihm dann eine Ergenissmenge präsentiert, die passend auf seine Suchanfrage ist. Auf einen Klick hin muß dieser Artikel dann in die erste freie Zeile des Formulars.
Wenn der User das 5 mal so macht, stehen also 5 ausgefüllte Zeilen dort und er kann es abschicken.
Frage Dich selbst, wie Du ein Szenario auswählen würdest. Gäbst Du eine Nummer und eine interne Bezeichnung ein - und den Preis noch vor?
Nur über eine Suchmaske, die Bezeichnung oder Szenariennummern findet.
Viele Grüße, Timo
Freundliche Grüße
Vinzenz