Inhalt eines abhängigen Kombinationsfeld unabhängig abspeichern

[MichaTH]

Hallo,

ich möchte den Einzelpreis, der an dem Primärschlüssel der Ressource eines Kombinationsfeldes hängt, unabhängig in einer Warenverkaufstabelle abspeichern.

Ich habe zu einem Hauptformular, das die Informationen zum Verkaufsvorgang und Daten aus der Tabelle "..Verkaufsvorgang.." enthält, ein Unterformular, in dem die einzelnen Waren mit Bezeichnung und Preis positionsweise und datensatzweise angelegt werden. Die Warenbezeichnung hole ich mit einem Kombinationsfeld aus einer Tabelle "..Warentabelle..". Die ..Warentabelle.. enthält neben dem Warennamen auch den Preis. Dieser wird beim Auswählen im Kombinationsfeld "ausgelesen", mit der Warenanzahl multipliziert und als Gesamtpreis im Formular angezeigt.

Gespeichert werden die Daten in einer Tabelle "..Warenverkaufsdetails..", die die Verknüpfung zum Primärschlüssel der Tabelle des Verkaufsvorganges des Hauptformulares enthält und den Primärschlüssel aus der ".. Warentabelle..".

Da sich der Preis der Waren ändern kann, aktualisiert sich auch jedesmal der Ware, wenn ich das Unterformular öffne. Ich möchte deshalb den Einzelpreis der Ware unabhängig in der Tabelle "..Warenverkaufsdetails.." abspeichern und suche hierzu eine Lösung.


Der Primärschlüssel der Tabelle "..Verkaufsvorgang.." ist verbunden mit dem Fremdschlüssel in Tabelle "..Warenverkaufsdetails..".
Der Primärschlüssel des Kombinationsfeldes, mit dem die Waren im Unterformular ausgewählt werden, ist verbunden mit dem Feld Ware im Unterformular und wird im Feld Ware in Tabelle "..Warenverkaufsdetail.." gespeichert. Für den Einzelpreis habe ich kein Feld in der Tabelle "..Warenverkaufsdetails..", weil der Preis bisher dynamisch ist. Um dies zu ändern, lege ich in der Tabelle "..Warenverkaufsdetais.." ein Feld an, das den Einzelpreis dann jedoch statisch und unabhängig von Preisänderungen irgendwie aus dem Kombinationsfeld Ware oder dem Feld, das den dynamischen Einzelpreis anzeigt, übernehmen soll.

Viel Worte, vielleicht gibt es eine viel kürzere Antwort. Ich möchte mich schon jetzt dafür bedanken fürs Lesen und noch mehr über eine Lösung.

Mit freundlichen Grüßen
Michael

[Bitsqueezer]

Hallo,

eigentlich ganz einfach: Den Preis mußt Du natürlich als neues Feld anlegen, die Preis-ID brauchst Du hier eigentlich gar nicht, eben genau aus dem Grund: Weil er sich ändern kann, aber beim Verkauf der verwendete Preis hinterlegt sein muß, nicht der aktuelle.

Du legst also ein neues Preisfeld an, dann verwendest Du eine Update-Abfrage, die die Preise aus der Preisliste holt und im Preisfeld speichert (denn sonst hast Du nachher gar keine Preise mehr drin).

Wenn das erledigt ist, kannst Du das Preis-ID-Feld löschen, das wirst Du nie brauchen (Preisinformationen für aktuelle Preise kannst Du jederzeit anhand des Artikels ermitteln).

Deine Kombobox brauchst Du an sich auch nicht, denn normalerweise hat man ja nur einen Preis für einen Artikel. Wenn Du aber je Situation unterschiedliche anbieten willst, kann die natürlich weiterhin so bleiben. Nur nicht bestehend aus ID und Preis, sondern nur aus Preis, was dann auch die gebundene Spalte ist. In der Abfrage der Kombobox mußt Du dazu nur das ID-Feld rausnehmen, die Kombobox auf 1 statt 2 Spalten stellen und die Spaltenbreite der ersten Spalte (i.d.R. 0cm) rausnehmen.
Ab da bekommst Du in der Kombobox für neue Positionen die aktuellen Preise gelistet und die werden bei Auswahl im Preisfeld gespeichert. Wenn sich der Preis in den Stammdaten ändert, ändert sich nicht mehr der Preis für die alten Positionen, nur noch, wenn Du eine neue anlegst.

Gruß

Christian

[MichaTH]

Hallo Bitsqueeer,

vielen Dank.

Ich bin in der ersten Kurve ausgestiegen. Vielleicht habe ich etwas undeutlich oder falsch dargestellt. Ich möchte gerade nicht, dass sich der Preis in der Tabelle "..Warenverkaufsdetail.." ändert, wenn sich in der Preis in der "..Warentabelle.." ändert. Er soll zwar bei der Eingabe eines Warenartikels der aktuelle sein, aber dann in der Tabelle "..Warenverkaufsdetails.." zusammen mit der Warenbezeichnung losgelöst von der Warentabelle gespeichert werden. 

Ich schau mir mein Modell nochmal an und möchte so lange meine Anfrage als gelöst auf Eis legen.

Ich bedanke mich für den schnellen Lösungsvorschlag.

Mit freundlichen Grüßen
Michael

[Bitsqueezer]

Hallo Michael,

ja, genau das habe ich oben beschrieben.
Wenn ich mal davon ausgehe, daß "Warentabelle" Deine Stammdaten beinhaltet mit den aktuellen Preisen und "Warenverkaufsdetails" die Daten mit der Auswahl des Preises beinhaltet, dann ist es genau so, wie beschrieben: In "Warenverkaufsdetails" wäre demnach ein neues Feld für Preis zu erstellen, in das der aktuelle Preis bei Auswahl über die Kombobox zu kopieren ist (durch die Auswahl in der Kombobox passiert das automatisch, wenn die Kombobox an das Preisfeld gebunden ist).

Ansonsten mußt Du mal mehr Details beschreiben, Tabellenaufbau, Formular usw.

Wenn Fragen sind, mußt Du halt fragen, was nicht klar war.

Gruß

Christian

[MichaTH]

Hallo Christian,

Sorry für die verzögerte Antwort. Es ist kein Ausdruck von Unhöflichkeit, ich habe schlicht mit keiner weiteren Antwort gerechnet. Umso mehr danke dafür. Ja genau so sind die beiden Tabellen angelegt und auch miteinander verbunden. Nein, eigentlich stehen in der Warentabelle die Waren, die zum Verkauf stehen, im Focus. Ein Feld in der Tabelle ist der Preis. Der Primärschlüssel dieser Warentabelle ist mit dem entsprechenden abhängigen Feld in der Warenverkaufstabelle verbunden. Und so zieht sich eine Abfrage immer den Preis, der aktuell in der Warentabelle für die Ware gilt, auch für die Datensätze, die abgeschlossen sind. Der Preis ist aktuell ein Feld in der Warentabelle und nicht in einer separaten mit der Warentabelle verbundenen Preistabelle.

Ich überlege noch Deinen Vorschlag. Verstehe ich es richtig, dass bei einer Preisänderung ein neuer Datensatz für die Ware erfasst werden muss. Oder kommt der Preis aus einer separaten Tabelle. Wie stelle ich es an, dass sich der Preis dann so verhält, dass bei einer Abfrage immer der Preis "gezogen" wird, der zum Zeitpunkt des Verkaufes gegolten hat.

Ich hatte vermutet, dass es einen Lösungsvorschlag gibt, den Preis eventuell aus der Warentabelle herauszunehmen und in einer weiteren und mit der Warentabelle verbundenen Tabelle abzulegen, mit mit der Abgrenzung gültig von und gültig bis zu versehen.

Jetzt habe ich aber Deinen Vorschlag gedanklich verlassen. Wie gesagt, ich überlege noch.

Gruß,Michael

[Bitsqueezer]

Hallo Michael,

es gibt immer viele Lösungsmöglichkeiten, nicht nur die eine richtige.

Wenn Deine Warenverkaufstabelle nach einem Verkauf einen neuen Datensatz erhält, der aktuell nur den Preis per Abfrage von einer Stammdatentabelle zieht, bekommst Du logischerweise immer den aktuellen Preis.

Wenn Du aber zum Zeitpunkt x eine Ware zu einem Preis verkauft hast, dann ist nur dieser eine Preis der für diesen Verkauf gültige.

Entsprechend mußt Du den Preis "einfrieren" - und daher gehört dann ein Preisfeld in die Warenverkaufstabelle, der Link zur Stammdatentabelle dient dann nur noch der Wareninformation, also z.B. Artikelname usw.

Der aktuelle Preis steht dann immer noch in der Stammdatentabelle, aber er wird nicht in die Abfrage für die Warenverkaufstabelle einbezogen (außer vielleicht für einen Preisvergleich).
Daher baust Du einfach ein Preisfeld in die Warenverkaufstabelle ein, und wenn die Ware verkauft wird und in der Kombobox der Preis aus der Stammdatentabelle steht, dann schreibst Du den Preis in das neue Feld in die Warenverkaufstabelle. Damit ist er hier separat gesichert, und beim Abfragen der Warenverkaufstabelle holst Du den Preis ausschließlich aus diesem Feld.

Das ist genauso bei etwa Rechnungen. Die Adresse wird immer redundant im Rechnungskopf gespeichert, denn das ist die zum Zeitpunkt der Rechnung gültige Adresse.

Ja, jeder redet über Normalisierung, aber echte Datenbankpraxis bedeutet auch, die Kunst der Denormalisierung zu beherrschen - denn das ist in der Praxis oft einfach nötig.

Was die Preise angeht, würde natürlich auch eine andere Variante funktionieren, die ist aber aufwendiger, dafür normalisierter. Dabei würde man bei jeder Preisänderung in einer getrennten Preistabelle die Artikel-ID, den Preis und das Datum, ab wann dieser gültig ist, speichern (das ist sogar eher die gängigere Variante, da man i.d.R. Informationen über Preisverläufe speichern möchte). Beim Abfragen einer Verkaufstabelle kann man dann anhand des Verkaufsdatums den zu dem Zeitpunkt gültigen Preis aus dieser Preistabelle ermitteln. In dem Fall benötigt man kein Preisfeld in der Verkaufstabelle.

Gültig Bis ist dabei nicht nötig. Gültig Bis ist Gültig Von des nächsten Preiseintrages. Und beim letzten Preis gibt es keinen Nachfolger, also ist Gültig Bis dann NULL, also "immer noch gültig".

Gruß

Christian