Hallo zusammen,
im Anhang habe ich eine Demo-Db, mit der ich Rabatte auf bestimmte Artikel berechnen möchte.
Leider komme ich an meine Grenze, dass wie gewünscht umzusetzen:
Im Bsp. möchte ich z.B. eine Kategorie auswählen und dann je nach Situation einen Mindestpreis angeben ab dem der folgende Rabatt berechnet wird.
Kategorie: Oberteil
mind. Preis: 20
Rabatt: 3%
Die daraus entstehenden Ds möchte ich dann in einer tblRabatt speichern.
Wie man sehen kann bin ich bis zur Auswahl der Kategorie gekommen, mind.Preis und Rabatt bekomme ich nicht bearbeitet.
Kann mir jemand von Euch helfen?
Gruß Torsten
Hallo,
Du solltest erst mal die Struktur der Tabellen verändern. Du hast auch keine Beziehungen angelegt.
Außerdem sind in den Tabelle überflüssige Felder. Wenn die Kategorie im Artikel festliegt, ist das Feld in den anderen Tabellen überflüssig. Du nutzt auch nicht den Primärschlüssel.
Und schließlich, wozu soll der Rabatt in eine Tabelle ? Eine Abfrage ist da völlig ausreichend.
Und die Tabelle mit dem Preis ist hier auch überflüssig, der Preis gehört einfach in den Artikel und die gewünschte Auswahl dann über eine Abfrage.
Der ganze Aufbau bedarf der gründlichen Überarbeitung. Das ist so für eine Datenbank unbrauchbar.
Im Grunde ist hier eine Tabelle völlig ausreichend, wenn Du in Deiner Beschreibung/Darstellung nicht einiges unterschlagen hast.
So ich habe die DB überarbeitet, ist es so besser um zum Ergebniss zu kommen?
Gruß Torsten
Hallo,
was hast Du denn überarbeitet, das ist immer noch falsch.
Und warum das in eine Tabelle soll ist auch unklar, Du brauchst doch da keine extra Tabelle für den Rabatt, das geht doch auch mit einer Abfrage.
Und überflüssige Felder sind immer noch drin.
Schaue Dir mal die DB im Anhang an. Alle 3 Felder ausfüllen und Anzeigen klicken.
Reicht das nicht ?
Hallo Klaus,
ich versuch Dich ja zu verstehen und sehe, dass Deine DB auf ein minimum reduziert ist.
Auch wenn in meinem Profil "Access-Profi" steht - ich verstehe nicht wirklich viel vom Programm, daher wohl auch meine DB die aus Deiner Sicht nicht so gut ist.
Warum soll das Ergebnis des Rabatts in eine Tabelle?
Weil ich das Ergebnis in ein Shop uploaden möchte, momentan ist das Ergebnis aber "flüchtig" und ich kann es nicht exportieren.
Gibt es da einen weiteren Ansatz?
Gruß Torsten
Zuerst solltest Du die Objekte ordentlich benennen. Ich habe es mir inzwischen abgewöhnt, Präfixe für Tabellen zu verwenden. Wenn man sie verwenden möchte, sollte man jedoch durchgehend bei einem Schema bleiben. Also entweder artikel und rabatt oder Artikel und Rabatt oder ARTIKEL und RABATT oder tblArtikel und tblRabatt oder tbl_artikel und tbl_rabatt - Mischformen verwirren.
Und Feldnamen wie art minus nr sind natürlich auch grausam. Beschränke Dich auf die Zeichen A..Za..z_0..9 bei Taufen von Objekten.
Wenn eine Tabelle ein Autowertfeld hat, sollte man es auch nutzen - ansonsten besser löschen.
Die Kategorie ist ein Kandidat für eine eigene Tabelle.
Preisangaben sollten vorzugsweise in Währungsfeldern gespeichert werden.
Es gilt, Pflichtfelder zu definieren.
Es gilt, Gültigkeitswerte festzulegen (z. Bsp. keine negativen Preise).
Wenn Du Rabatte vergeben willst, muss es auch Angaben (z. Bsp. in Form von Mindestabnahmemenge) geben, ab der ein Rabatt zur Geltung kommt.
Wenn Du Dich mit den Mindestmengen anfreundest und vermutlich weitere Tabellen mit Artikelinformationen bestücken willst, überlege, ob es am einfachsten ist, einen Standard-Rabatt von 0% zu vergeben. Das hat den Vorteil, dass alle Artikel über den Rabatt referenziert werden können und die Rechenformel konstant bleibt.
Weil weder Artikelpreise noch Rabatte in Stein gemeißelt sind, ist es sinnvoll, wenn keine weitere Marktforschung betrieben wird, Artikelpreise und vergebene Abzug-Prozente auch in Detailtabellen beim Verkauf der Artikel zu führen. Ansonsten müssten sowohl für Preise als auch für Rabatte Historien angelegt werden, damit Bezüge auf die originalen Preise und Rabatte erhalten bleiben. Du kannst Dir auch Oracle in der Express-Version oder timescaledb installieren - da entfällt diese Anforderung dann. :)
Im Anhang ist ein Bild des Beziehungsfensters, wie Deine beiden Tabellen minimal aussehen könnten.
@Klaus
Gibt es noch eine Möglichkeit das Ergebnis des Formulars in eine Tabelle für den upload zu bekommen?
Ich bitte um Deine Hilfe.
Freundliche Grüße
Hallo,
Du brauchst keine Tabelle, Du kannst auch eine Abfrage für den Export verwenden. In der Abfrage wird wie im Formular mit dem Rabatt gerechnet.
Hallo zusammen,
ich konnte mich wieder mit meiner DB beschäftigen.
Ein Probleme habe ich jetzt noch:
In der erstellten Abfrage habe ich unter "artpreis" >[Formulare]![frmArtikel]![txtMindPreis] als Kriterium eingegeben,
damit der Wert des mind.Preis in die Abfrage übernommen wird - funktioniert.
Nur das führt dazu das im Formular die gewählten Datensätze nicht mehr angezeigt werden. Geht das auch anders?
Hat da jemand von Euch eine Idee, die mir weiterhilft?
Anbei die aktualisierte DB.
Vorab vielen Dank, Gruß Torsten
Ohne Datenmodellierung wird das nichts. Ich bin wegen Beratungsresistenz raus aus dem Thread.
Was meinst Du mit Datenmodelierung... dann erkläre mir es doch bitte im konkreten Fall.
Es kann doch nicht daran liegen ob eine Feld-Bez. art-nr oder art_nr oder artnr heißt.
Hallo Torsten,
Schau dir dies an.
gruss ekkehard
Hallo Ekkehard,
ich verstehe in soweit Deine Demo-DB, vielen Dank für die Mühe.
Ich werde daran orientiert meine DB umarbeiten, zumal es für mich sehr viel einfacher ist von einer Vorlage "abzugucken" um das Prinzip zu verstehen und dann auf meine Details anzupassen.
Nur wie bekomme ich das Ergebnis des Formulars in eine Tabelle oder Abfrage damit ich die dann vorhandenen Daten in die MySQL-Tabelle des Shops exportieren kann?
Gruß Torsten
Ich hab nochmal das Formular um den "Rabattpreis" ergänzt, denn der muß auch exportiert werden.
Hallo Torsten,
Zum Exportieren brauchst du dann wieder eine Abfrage (hatte ich
gelöscht, da als DS-Herkunft nicht geeignet). In dieser wird dann auch
der Rabatt-Preis berechnet.
gruss ekkehard
Hallo Ekkehard,
das sieht gut aus. Ich werde das jetzt auf meine Daten anpassen.
Vielen Dank
Gruß Torsten
Hallo Torsten,
Mir ist gerade noch aufgefallen, das die Abfrage zwar korrekt funktioniert,
aber sie nicht ganz korrekt formuliert ist.
Ersetze sie durch diese
SELECT
A.ArtikelID,
A.artnr,
A.artname,
A.kategorieID_F,
A.artpreis,
A.artpreis*(1-Forms!frmArtikel!txtRabattEingabe/100) AS rabatt_preis
FROM tblArtikel AS A
WHERE
A.kategorieID_F=Forms!frmArtikel!cbxKategorieFilter
AND A.artpreis>=Forms!frmArtikel!txtMindPreisFilter
gruss ekkehard
Moin Ekkehard,
Deinen Nachtrag habe ich geändert.
Boah, in der Demo-Db sind für mich soviel neue "Sachen", dass ich nur staunen kann.
Ich werde mich die Tage damit befassen und werde sicherlich einige Fragen haben um zu verstehen was warum gemacht wurde um zum Ergebnis zu kommen.
Vielen Dank bis hierhin.
Gruß Torsten
Hallo Torsten,
Na ja, das ist ja noch unterste Stufe (1. Normalform).
Was ich gemacht habe:
1. Die tblKategorien angelegt und mit den ersichtlichen Kategorien bestückt.
2. In der tblArtikel dein Textfeld Kategorie in das FK-Feld KategorieID_F geändert
(Datentyp: Zahl, Long Integer) und entsprechend befüllt.
3. Die Beziehung zwischen den Tabellen angelegt.
4. Das Formular
a) an die tblArtikel gebunden (statt an deine Abfrage)
b) die Felder zum Filtern (Formkopf) umbenannt und als DS-Herkunft des Kombis
die tblKategorien eingetragen
dieses Kombi filtert das Form schon mal auf die ausgewählte Kategorie vor
siehe Ereignisprozedur "cbxKategorieFilter_AfterUpdate()"
c) das Feld "Kategorie" im Detailbereich in ein Kombi gewandelt, DS-Herkunft wie
oben, und an das Feld "KategorieID_F" gebunden
d) der Button zum Anzeigen filtert dann den Rest aus
wo ich das gerade so schreibe ist mir aufgefallen, dass da noch ein Fehler drin
steckt (Korrektur s. u.)
e) und der andere Button setzt den Filter zurück; - hattest du schon, ich hab's nur
formatiert
Korrektur (s.o.)
ZitatPrivate Sub btnAnzeigen_Click()
Me.Filter = "kategorieID_F = " & Me.cbxKategorieFilter & " And artpreis >= " & Str(Nz(Me.txtMindPreisFilter, 0))
Me.FilterOn = True
End Sub
(i.Ü.: Str ersetzt das Dezimal-Komma durch einen Punkt; Nz verwendet 0 als mind.
Preis wenn das Feld leer ist)
Und zum Schluss dann noch die Abfrage für den Export erstellt incl. Berechnung der
Preise abzügl. Rabatt.
Ob diese von den Feldern und deren Reihenfolge her den Anforderungen der Weiter-
verarbeitung entspricht kannst nur du wissen.
gruss ekkehard
@Ekkehard,
(bitte nicht falsch verstehen - aber das gehört IMHO mit zur Datenmodellierung)
was nicht sein dürfte (DS 6-8):
tblKategorien | KategorieID | KatName | 1 | hose | 2 | oberteil | 3 | fußbekleidung | 5 | unterwäsche | 6 | A | 7 | A | 8 | (Null) |
Was auch nicht sein dürfte (DS 14, 15):
tblArtikel | ArtikelID | artnr | artname | kategorieID_F | artpreis | 1 | 01 | jeanshose | 1 | 29,95€ | 2 | 02 | bluse | 2 | 19,95€ | 3 | 03 | hemd | 2 | 24,95€ | 4 | 04 | latzhose | 1 | 29,50€ | 5 | 05 | weste | 2 | 39,95€ | 6 | 06 | strümpfe | 3 | 7,95€ | 7 | 07 | socken | 3 | 12,50€ | 8 | 08 | schuhe | 3 | 49,90€ | 9 | 09 | sandalen | 3 | 17,92€ | 10 | 10 | shorts | 1 | 9,99€ | 11 | 11 | lätzchen | 2 | 4,95€ | 12 | 12 | unterhemd | 5 | 7,95€ | 13 | 13 | unterhose | 5 | 4,95€ | 14 | (Null) | (Null) | (Null) | (Null) | 15 | (Null) | (Null) | (Null) | -23,75€ |
|
|
Hallo Lachtaube,
Zitatbitte nicht falsch verstehen
Sicher nicht. Du hast ja Recht, da war ich schlurig.
Besser so?
gruss ekkehard
Viel besser Ekkehard :)
Anmerkung:
>0 reicht als Gültigkeitsregel aus und impliziert ein NOT IS NULL
Bei eingestellter referentieller Integrität ist in Access bereits ein Index involviert (daher doppelt gemoppelt).
Zitat>0 reicht als Gültigkeitsregel aus und impliziert ein NOT IS NULL
Bei mir nicht; - ohne diese Bedingung wird bei mir ein leeres Feld nicht muckiert.
An den automatisch gesetzten Index hatte ich nicht gedacht.
gruss ekkehard
Mit der Gültigkeitsregel war ich auf dem falschen Dampfer. :)
Moin Ekkehard,
nochmals vielen Dank für die ausführliche Erklärung warum, wieso, weshalb.
Ich konnte alles an meine Daten anpassen und habe nun ein komfortables Tool um flexibel Angebotspreise im Shop zu realisieren.
Auch noch Dein Nachtrag das Feld MindPreis nicht explizit auszufüllen ist hilfreich
und ich habe nun einen Text/Code der mir die Berechnung des Rabatts in nur einem Feld ermöglicht :)
A.artpreis*(1-Forms!frmArtikel!txtRabattEingabe/100)
Ich habe aber noch eine Frage:
In der Abfrage "Kopie von qryArtikelExport" änderst Du in
SELECT A.ArtikelID, A.artnr, A.artname, A.kategorieID_F, A.artpreis, A.artpreis*(1-Forms!frmArtikel!txtRabattEingabe/100) AS rabatt_preis
FROM tblArtikel AS A
WHERE (((A.kategorieID_F)=[Forms]![frmArtikel]![cbxKategorieFilter]) AND ((A.artpreis)>=[Forms]![frmArtikel]![txtMindPreisFilter]));
die Herkunftstabelle wird nun als A bezeichnet. Warum wird sowas gemacht?
Noch angenehme Ostertage und freundliche Grüße
Torsten
Hallo,
das sind Aliasnamen. Damit wird der Abfragetext kürzer und übersichtlicher weil statt tblArtikel kann man dann einfach A schreiben.
Wobei bei einer Tabelle auch der Tabellenbezug bei den Feldern entfallen könnte. Auch die Klammern sind zu viele.
SELECT ArtikelID, artnr, artname, kategorieID_F, artpreis,
artpreis*(1-Forms!frmArtikel!txtRabattEingabe/100) AS rabatt_preis
FROM tblArtikel AS A
WHERE A.kategorieID_F=[Forms]![frmArtikel]![cbxKategorieFilter]
AND A.artpreis>=[Forms]![frmArtikel]![txtMindPreisFilter]
Ok, verstehe.
Und bei einer weiteren Tabelle in der Abfrage kann ich die dann als B bezeichnen, und weiter C,D usw.?
Gruß Torsten
Hallo,
da nimmt man dann zweckmäßigerweise passende Buchstaben. A=Artikel.
Es ist vorteilhaft, wenn man an den kurzen Aliasnamen auf die eigentliche Tabelle schließen kann. Daher können auch 2 Buchstaben sinnvoll sein.
@Klaus
Danke für deine Erläuterungen für den TS.
ZitatAuch die Klammern sind zu viele.
Da hat er die Abfrage wohl erst noch mal im Editor geöffnet und Access hat
die Klammern wieder gesetzt (fürchterliches "Feature"). Bei mir gibt es noch
nicht einmal die eckigen.
gruss ekkehard