Wert aus Abfrage in Formulartextfeld anzeigen lassen

[ellinho]

Hallo zusammen.

Ich habe eine Artikelbestandsliste (Tabellenname "Artikelbestand), in die über ein Formular die Wareneingänge mitsamt Zugangsdatum und Einkaufspreis netto geschrieben werden. Die Tabelle "Artikelbestand" besteht aus den Spalten ID, Bezeichnung, EKPreisnetto, Datum, Zu-/Abgang. Genauso habe ich ein Formular für die Warenausgänge erstellt. Bei dieser Buchung wird vom Benutzer natürlich kein Einkaufspreis netto mitgegeben, allerdings sollte das vom System erledigt werden (dies kann auch ruhig versteckt im Hintergrund ablaufen), denn ansonsten habe ich nie den genauen Wert, der auf dem Lager liegt. Ich habe nun eine Abfrage erstellt, die den Durchschnitts-Einkaufspreis netto für jeden Artikel berechnet. Diese heißt "EKPreisMittelwert" und besteht aus den Spalten Bezeichnung und EKPreisnetto.
Nun möchte ich ein Textfeld in das Formular "Warenausgang_buchen" integrieren, das den Durchschnitts-Einkaufspreis netto aus der Abfrage "EKPreisMittelwert" des über Kombinationsfeld ausgewählten Artikels anzeigt und beim Erfassen des Warenausgangs dann auch mit in die Tabelle "Artikelbestand" schreibt.
Ich hoffe, man kann verstehen, was ich meine und würde mich freuen, wenn mir jemand von Euch helfen kann.
Vielen Dank schon mal.

Gruß Karsten

[DF6GL]

Hallo,

zu verstehen ist das schon, nur das Konzept dahinter ist fragwürdig.  Aktuell aus anderen Daten berechnete Werte soll(t)en nicht in Tabellenfelder abgelegt werden. 

Zudem ist mir die Bedeutung von "Bezeichnung" suspekt.  Wenn das die Artikelbezeichnung sein soll, ist der Tabellenaufbau nicht db-gerecht und korrekt.  Es fehlt die eigentliche Artikeltabelle (mit Primärschlüsselfeld) und in "Artikelbestand" das Fremdschlüsselfeld zum Aufbau einer Beziehung zwischen den beiden Tabellen.   "Artikelbestand"   sollte dann auch eher "Lagerbewegungen" heißen, in der zusätzlich der Lagerort (bzw. die Lagernummer, falls überhaupt vorhanden) mitgeführt werden.   Beim Feld "Zu-/Abgang"  (heißt das wirklich so? Wenn so, dann unbedingt auf Sonder- und Leerzeichen im Namen verzichten!)  muss weiterhin vereinbart (definiert) werden, dass Lagerzugänge positiv und Lagerabgänge negativ gebucht werden.  "Menge" wäre eine alternative Benennung, wobei evtl. auch Mengeneinheiten berücksichtigt werden müssen/können.  Sollen in "Menge" immer nur positive Zahlen stehen, ist um ein weiteres (Ja/Nein-)Feld ("Bewegungsart" : 0= Zugang, -1 = Abgang) zu erweitern.


Die Berechnung der Mittelwerte wird dann und dort durchgeführt, wo diese Daten aktuell verwendet werden.

[ellinho]

Hallo Franz.
Vielen Dank für Deine Antwort.
Ich werde das bezgl. Primär- und Fremdschlüssel und vernünftigen Bezeichnungen noch mal überarbeiten. Lagerzugänge werden aktuell bereits automatisch positiv, Lagerabgänge automatisch negativ gebucht.
Allerdings verstehe ich den letzten Satz noch nicht. Ich muss doch mit einer Abfrage arbeiten, um den Mittelwert für den Netto-EK pro Stück zu berechnen!?!?
Beispiel: Ich kaufe 10 Stück von Artikel1 zu einem Preis von 5,60 EUR/Stck. ein. Danach kaufe ich 15 Stück von Artikel1 zu einem Preis von 5,75 EUR/Stck ein. Somit habe ich von Artikel1 einen Lagerbestand von 25 Stück. Der Durchschnitts-Netto-EK läge somit bei 5,69 EUR/Stck. Wenn ich nun 5 Stück aus dem Lager buche, ändert sich doch, wenn ich nicht wieder den zur Buchung aktuellen Durchschnitts-Netto-EK in die Tabelle "zurückschreibe", der Durchschnitts-Netto-EK auf 7,11 EUR/Stck, obwohl er, wenn ich 5 Stück mit Durchschnitts-Netto-EK von 5,69 EUR/Stck. ausbuche, richtigerweise auf 5,69 EUR/Stck bleibtDas kann ich doch nur über eine Abfrage berechnen, oder nicht??? Das Formular, über das der Warenausgang gebucht wird, muss aber doch wiederum mit der Tabelle, die die Lagerbewegungen enthält, "verknüpft" sein. (Datensatzquelle)!?! Somit hat sich die Anzahl der Fragezeichen bei mir nicht reduziert. 

VG
Karsten

[DF6GL]

Hallo,

ich habe nirgends bestritten, dass der Preis über (irgend-)eine Abfrage berechnet werden kann.   

Zum "Mittelwert" gibt es ja einige unterschiedliche Definitionen.  Bzgl. Lagerhaltung suchst Du vielleicht  ja den "gleitenden Durchschnittspreis".  Wie auch immer,  Abgänge spielen IMHO für diese Berechnung keine Rolle, nur die Zugänge, und dann auch nur in einem bestimmten Zeitraum. 

[Beaker s.a.]

Hallo Karsten,
Den durchschnittlichen Ek-Preis berechnet man normalerweise nicht
als Mittelwert aller Einkäufe, sondern, wie Franz schon anmerkte als
"gleitenden Durchschnittspreis":
(Bestand x alter dEK + Zugang x neuer EK) / neuer Bestand.
Und den würde ich als Eigenschaft (Feld) im Artikelstamm führen, und
bei Zugängen entsprechend neu berechnen.
gruss ekkehard

[ellinho]

@Ekkehard

Vielen Dank für den Gedankengang.
Ich gebe bei Wareneingängen zwar den Netto-EK mit, allerdings schreibe ich nicht in den Artikelstamm, sondern in eine Tabelle "Lagerbewegungen". Somit kann ich den "gleitenden Durchschnittspreis" nicht als Eigenschaft (Feld) im Artikelstamm führen, oder doch  
Und noch ein Problem: Wie bekomme ich denn wohl am besten den alten dEK errechnet?
Gruß Karsten

[Beaker s.a.]

Hallo Karsten,

Wie bekomme ich denn wohl am besten den alten dEK errechnet?

Deshalb speichere ich ihn ja im Artikelstamm, um beim nächsten Einkauf
darauf zugreifen, ihn neu berechnen und aktualisieren zu können.
gruss ekkehard

[ellinho]

Aber wie? Über einen Trigger beim Buchen des Wareneingangs? Oder geht es auch anders?

[Beaker s.a.]

Hallo,
Tja, hm, kenne ja deine Abläufe nicht.
Mein erster Ansatz wäre erstmal eine Function, die den neuen Wert
berechnet. Das gleich in eine Aktualisierungsabfrage zu packen würde ich
mich an dieser Stelle nicht zutrauen. Also mit der Function wohl schon,
was ich meine ist die Berechnung direkt in einer Abfrage.
gruss ekkehard

[ellinho]

@Ekkehard

Mit einer Abfrage hatte ich bereits geplant - nur noch keine Idee, wie !?!
Du hattest die Berechnung ja schon in einem Deiner Beiträge geschrieben:
(Bestand x alter dEK + Zugang x neuer EK) / neuer Bestand
Nun tue ich mich schwer, die "alten Werte" zu berechnen, d.h. den alten Bestand vor letztem Warenein-/ausgang sowie den alten dEK. Ich muss ja quasi dabei rechnen: aktueller Bestand - letzter Datensatz. Da "hänge" ich. 

VG
Karsten

UPDATE:

Ich habe nun schon mal 2 Berechnungen erstellen können, mit denen ich zum einen die letzte Lagerbewegung berechnen kann das mache ich mit MAX(ID) zum anderen den Bestand vor letzter Bewegung. Wenn ich jetzt jedoch den gleitenden Durchschnitts-Netto-EK berechnen möchte, stoße ich auf folgende Schwierigkeit: Ich benötige ja dafür den letzten Wareneingang. Diesen kann ich mit meiner MAX(ID)-Funktion nicht ermitteln, da ich Wareneingänge und -ausgänge in der Tabelle stehen habe. Ich kann zwar über den Grund "Wareneingang" filtern, bekomme jedoch dann alle Wareneingänge angezeigt. Wie bekomme ich den letzten Wareneingang herausgefiltert? Ich könnte mit der ID bzw. mit dem Buchungsdatum arbeiten. Aber wie???

Viele Grüße
Karsten

[Beaker s.a.]

Hallo,

zum anderen den Bestand vor letzter Bewegung

Die letzte Bewegung ist für diese Berechnung der neue Wareneingang; -
also der aktuelle Bestand vor dem Zugang.
Den Bestand berechnest du ja aus den Lagerbewegungen.

Wenn ich jetzt jedoch den gleitenden Durchschnitts-Netto-EK berechnen möchte, stoße ich auf folgende Schwierigkeit: Ich benötige ja dafür den letzten Wareneingang.

Wozu? Welchen Wert willst du da rausholen?
Ich gehe ja davon aus, dass der gleitende dEK, nach der Neuberechnung
beim Wareneingang, irgendwo gespeichert wird. Diesen Wert musst du zum
Zeitpunkt der Berechnung von dort abholen.
gruss ekkehard

[ellinho]

@Ekkehard
Dankeschön. Ich löse das nun mit einem Trigger, der mir bei jedem Wareneingang den Netto-EK mitsamt Eingangsmenge in eine Hilfstabelle schreibt. Diese nehme ich als Grundlage zur Berechnung.

Viele Grüße
Karsten

[Beaker s.a.]

Hallo Karsten,
Wozu Hilfstabelle? Wie speicherst du den die Zugänge?
Wareneingang läuft bei mir wie der Ausgang auch, über einen
Lieferschein mit Einzelpositionen. Und da werden auch EK und
Menge erfasst und gespeichert. Der letzte Zu-/Abgang lässt
sich dann über das Datum des LS ermitteln.
gruss ekkehard

[ellinho]

@Ekkehard

Ich habe wahrscheinlich ein Brett vor dem Kopf 
Sämtliche Werte errechne ich aktuell über Abfragen. Den Bestand vor dem letzten Wareneingang, den letzten Zugang, den Netto-EK des letzten Zugangs und den neuen Bestand. Nur den alten dEK bekomme ich nicht. Ich habe mal eine Tabelle (aktueller_DEK) erstellt (Felder: Artikelbezeichnung und DEK) und würde ihn ja daraus auslesen - allerdings muss Access diese Tabelle zunächst einmal mit einem Datensatz befüllen. Ich habe mir überlegt, eine Aktualisierungsabfrage zu erstellen, die diese Tabelle im Falle eines Wareneingangs aktualisiert. Allerdings weiß ich im Moment leider absolut nicht, wie.  Kannst Du mir vielleicht weiterhelfen?

Viele Grüße
Karsten

[Beaker s.a.]

Hallo Karsten,

Sämtliche Werte errechne ich aktuell über Abfragen

Ist ja nicht verkehrt. Abfragen beruhen aber immer auf Tabellen, also
gespeicherten Werten.

Den Bestand vor dem letzten Wareneingang

Wie gesagt, das ist der aktuelle Bestand vor dem aktuellen Zugang.

den letzten Zugang, den Netto-EK des letzten Zugangs

= der aktuelle Zugang

eine Tabelle (aktueller_DEK) erstellt (Felder: Artikelbezeichnung und DEK)

Macht Sinn, da du so auch eine Historie der dEKs hättest.
Aber nur, wenn du
1. nicht die Artikelbezeichnung sondern den PK aus der tblArtikel
als FK übernimmst, und eine entsprechende Beziehung anlegst
2. ein Datumsfeld ergänzt

allerdings muss Access diese Tabelle zunächst einmal mit einem Datensatz befüllen.

Na ja, einen Startwert musst du schon irgendwie "ermitteln" und
in die neue Tabelle bringen. Ich würde da einfach den EK des letzten
Zugangs vor dem aktuellen nehmen.

Ich habe mir überlegt, eine Aktualisierungsabfrage zu erstellen, die diese Tabelle im Falle eines Wareneingangs aktualisiert.

Würde ich wohl auch so machen. Wobei mir halt immer noch nicht
klar ist, wie der Wareneingang bei euch erfasst wird; - manuell (jeder
Artikel einzeln) oder über einen Eingangsbeleg mit Positionen (alles auf
einen Rutsch)?

gruss ekkehard