Access - Formularproblem

A

Akuma

Benutzer
Beiträge
6
Hallo Zusammen,

ich bin ein völliger Neuling in Access und soll für meine Firma eine Lagerkartei mit Access erstellen.
Nun habe ich mir alles soweit durch Forums, Freunde und Google selbst beigebracht - hänge aber an einer Stelle.

Ich erläutere mal das Problem:

Ich habe zwei Tabellen erstellt - eine tblArtikel (wo die Artikel für das Lager angelegt werden - Art-Nr, Artikelbezeichnung, Lagerplatz) und eine tblBestandsänderung (wo die Zu- und Abbuchen gelistet werden - Artikelnummer, Lagerplatz, Artikelbezeichnung, Menge, Datum).

Ebenfalls habe ich fünf Formulare erstellt - Zubuchen, Abbuchen, Artikel-, Gesamt- und Bestandübersicht.

Und bei den Beiden ersten Formularen (Zu- und Abbuchen) ist nun auch der Fehler. Sobald ich einen Artikel mit Menge zubuche - wird die Bezeichnung des Artikels nicht in der tblBestandsänderung übernommen. Dieses Feld bleibt leer. Mein Gedanke war, dass dieser sich automatisch ausfüllt, wenn ich in den Formularen Zu- und Abbuchen den Lagerplatz auswähle.

Zuerst dachte ich, ich könnte dies mit einem DomWert lösen, doch hat das nicht funktioniert. Auch durch die Beziehungen von tblArtikel zu tblBestandsänderung hatte keinen wirklichen Erfolg.

Nun sitze ich schon so lange an dieser Datenbank, dass mir keine weiteren Lösungsansätze mehr einfallen - vielleicht könnt ihr mir ja helfen.

Liebe Grüße
Lisa
 
Werbung:
Hallo Lisa,
das ist sicher möglich. Es wäre gut, wenn Du eine abgespeckte und anonymisierte Version der DB hier hochlädtst.

Ich denke, es ist keine besonders große Firma, wenn die Lagerhaltung in Access gemacht und von einer Autodidaktin gepflegt wird. Ich will deine Leistung nicht geringschätzen, im Gegenteil. Ich weiß ja nicht, was Ihr sonst so an EDV einsetzt. Auftragsverwaltung, Buchhaltung, Bestellwesen. Ich möchte das nur Eurem Chef ans Herz legen. Es gibt zig integrierte ERP-Anwendungen, auch zu kleinerem Kurs, sodass auch eine kleine Firma das stemmen kann. Die Programme sind immer auf dem neusten Stand und durchdacht von Profis erstellt. Trotzdem ist Access in vielen Fällen eine gute Wahl, sollte aber im Falle von professioneller Anwendung nicht als "Bastelanwendung" betrieben werden. Es gilt also zu hinterfragen, was in Sachen EDV für Euch die MIttel der Wahl sind.
 
Hallo Andreas,

danke für deine Rückantwort.
Ich werde dieses Thema mal mit meinem Chef durchgehen.

Ich habe die Datei angehängt und hoffe, dass Sie mir weiterhelfen können.

Verbesserungsvorschläge nehme ich sehr gerne an.

Liebe Grüße
Lisa
 

Anhänge

Zuletzt bearbeitet:
Hallo Lisa,
ich habe mir die DB angesehen. Es ist so, wie es eigentlich immer ist. Es wird sich zu früh an Abfragen, Formulare und Berichte abgearbeitet, ohne vorher das Datenmodell mit Tabellen und Beziehungen korrekt aufzubauen.

Der Reihe nach:
Es ist durchaus richtig mit IDs zu arbeiten, immer dann wenn der Datensatz eindeutig sein soll und es keinen anderen eindeutigen Schlüssel gibt.
Im Fall einer Artikelstammtabelle ist das meistens unnötig, weil Artikelnummern ja genau den Zweck haben den Artikel eindeutig zu identifizieren. Also kann die ArtNr zum Primärindex werden und die ID entfallen. Das vereinfacht Dir die Arbeit später sicherlich.

Die Tabelle Bestandsänderung würde ich in Bewegungen umbenennen. Hier ist die ID absolut sinnvoll um jeden Bewegungssatz eindeutig ansprechen zu können. Als Fremdschlüssel schafft die Arikelnummer dann die Verbindung zum Artikelstamm.
Desweitern ist es nicht nötig je ein Feld für Abgang und Zugang zu definieren. Abgänge sind negativ und Zugänge positiv. Stattdessen würde ich ein Feld Bewegungsart definieren um später auch andere Bewegungsarten kennzeichnen zu können, z.B. Inventurbuchung, ungeplante Korrektur, etc. Wichtig ist das auch um die Bewegung wertmäßig richtig zu bewerten (wertmäßige Bestandsführung). Zugänge aus Bestellungen werden mit dem Einkaufspreis bewertet. Abgänge auf Rechnung mit dem VK. Komplizierter wird es bei anderen Bewegungen. Weil es ja über einen Zeitraum mehrere Einkäufe zu unterschiedlichen Preisen geben kann, muss ein (Inventur)Bestand mit dem gleitenden DurchschnittsEK oder mit dem letzten EK, je nachdem, was niederiger ist, bewertet werden (Niederstwertprinzip).

Was Du bisher gebaut hast ist eigentlich keine Datenbank und ließe sich in Excel auch abhandeln. Soll heißen, die Tabellen sind nicht normalisiert. So müsste es auch noch eine Tabelle Lagerorte geben, allein um bei der Eingabe prüfen zu können, ob es den LO überhaupt gibt. Genauso verhält es sich mit Lieferant, ggf. Kunde und später auch mit Bestellnummer. Wobei Bestellnummer hier auch nicht gut ist. Das würde ich in Belegnummer ändern, denn es könnte bei Abgängen ja auch eine Rechnungs- oder Auftragsnummer sein.
Hinter Benutzer könnte auch noch eine Tabellen "gültige Benutzer" stehen um die Buchungsmasken auf bestimmte Nutzer/PC zu beschränken. Sicher darf nicht jeder PC/Angestellte jede Art von Buchung durchführen.

Nun gilt es die Tabellen richtig und vernünftig in Beziehung zu setzen. Die Beziehungen, so wie Du sie eingerichtet hast, sind suboptimal. Du solltest Dich nochmal mit den Begriffen 1:1, 1:n, m:n - Beziehung, Normalisierung von Tabellen und referentielle Integrität auseinandersetzen.
Hierzu gibt es im Netz viel zu lesen und es ist für Datenbankdesign unerlässlich sich damit auszukennen.

Erst wenn das Gerüst gut steht wirst Du die Vorteile von Access richtig nutzen können. Abfragen, Formulare und Berichte sind dann schnell und häufig mit Hilfe der vielen Assistenten leicht erstellt.

Hier noch eine paar grundsätzlich Empfehlungen, die ich geben möchte:
Nutze in Tabellen keine berechneten Felder und keine Nachschlagefelder. Die führen später zu vielen Missverständnissen bei Abfragen, etc. Versuche Makros zu vermeiden, sondern lerne stattdessen VBA. Aber das machst Du ja, wie ich an den Aufrufen bei den Buttons gesehen habe.

Ansonsten ist deine Arbeit sauber und strukturiert. Ich hoffe ich konnte einige Anregungen geben. Wenn Du deine DB überarbeitet hast zeig sie gerne nochmal und bei Problemen gerne melden.
 
Hallo Andreas,

vielen Dank für den großen Denkanstoß!
Ich werde die DB überarbeiten und mich vorher nochmals über die Beziehungen lesen/lernen.

Eine kleine Frage hätte ich jedoch noch:

Bezüglich der Ab- und Zugänge.. Kannst Du das bitte nochmal erläutern?
Wie sollte ich das Feld stattdessen benennen? "Ab-/Zugang"? Und wie stelle ich es ein, damit die Beträge negativ, bzw positiv angezeigt werden?

Liebe Grüße
Lisa
 
Hallo Lisa,
ich würde es einfach Menge nennen. Da es ein Zahlenfeld (Double) ist, wird es mit Vorzeichen in Access verwaltet und angezeigt. Dann weisst Du immer, daß Du richtig rechnest. Wenn Du einen Abgang als positiven Wert in einem Formular anzeigen möchtest kannst Du ihn einfach im Formularfeld *(-1) nehmen. Aber Vorsicht dann beim Rechnen innerhalb des Formulars und , dass Du immer richtig in die Tabelle schreibst. Zu prüfen ist das dann jeweils anhand der Bewegungsart. Es sind dann auch nicht zwei Formulare für Zu-, bzw, Abgänge nötig.
 
Hallo Andreas,

ich habe nun die Tabellen mit Beziehungen verbunden und so scheint das Ganze auch zu funktionieren. Danke schonmal dafür!
Jetzt möchte ich das Ganze noch in ein Formular packen.

Dazu hätte ich eine kleine Frage:

Ich möchte gerne, dass der Lagerort durch ein Kombinationsfeld auswählbar ist und sich die Artikeldaten in den Textfeldern automatisch ausfüllen, damit der Lagerist nur noch die Menge und die Bestellnummer/Rechnungsnummer ausfüllen muss. Ist das möglich?

Habe versucht ein Formular mit den funktionierenden Tabellen zu erstellen, doch nimmt er die Artikel nicht aus der Artikeltabelle, wenn ich das Kombinationsfeld auswähle. Muss ich das mit VBA machen?

Entschuldige, wenn ich zu viele Frage stelle.


Liebe Grüße
Lisa
 
Guten Morgen Lisa,
zuerst die Frage, hat jeder Artikel eine festen Lagerort? Dann ist das eine andere Beziehung, als wenn ein Artikel auf vielen, beliebigen Lagerorten liegen kann (sogenannte "chaotische Lagerführung". Je nachdem muss die Abfrage, die dem Buchungsformular zugrunde liegt, aufgebaut sein. Das Kombinationsfeld Lager hat eine eigene Datenherkunft. Die Abfrage enthält dann eine 1:1 Beziehung zum Artikel. Wenn Du dann das Hauptformular baust sind alle Daten des Artikels in deiner Abfrage enthalten und Du hast sie auch im Hauptformular am Wickel. Das Unterformular beinhaltet dann die Bewegungen. Der Container, in dem das Unterformular im Hauptformular liegt, kann dann entweder über Artikel, oder über Lagerplatz verbunden sein, weil es ja eine 1:1 Beziehung ist.

Egal ob 1:1 oder 1:n, ich würde das Buchungsformular über den Artikel steuern und nicht über den Lagerplatz, weil man dann im Unterformular alle Lagerorte des Artkels sieht und buchen kann. Wenn es nur einen gibt, seis drum.

Kommen in einer Lieferung mehrere Artikel, oder gehen mit einem Auftrag mehrere Artikel raus, ist das nochmal ein anderes Ding. Dann sollte die Buchung anhand der Bestellung, bzw. des Lieferscheins/Rechnung erfolgen.

Zeige ruhig bei Gelegenheit die Ergebnisse deiner Arbeit. Ich freue mich, wenn ich weiterhelfen kann.
 
Hallo Andreas,

vielen Dank :)

Jeder Artikel hat seinen eigenen Lagerort. Habe die Tabellen mit einer 1:n Beziehung verbunden.
Soweit scheinen diese auch zu funktionieren, wenn ich bei der Tabelle 'Lagerort' auf das kleine [+] drücke, kann ich alle Daten nach und nach eingeben.

Die Artikel dürfen aber nur von meiner Kollegin und mir eingegeben werden. Deswegen ist es wichtig, dass die Lageristen nur die Menge, die Bewegungsart, das Datum, die Belegnummer, den Preis und den Lieferanten eingeben dürfen.

Ohne Formular sehen sie in der Tabelle tblBewegungen leider nicht den Lagerplatz bzw. die Artikelbezeichnung.

Ich hoffe, ich habe dies richtig formuliert.

Habe mal meine bisherige DB angehängt.

Danke schon Mal im Voraus.

Liebe Grüße
Lisa
 

Anhänge

Hallo Lisa,
ich habe mal ein Grundgerüst aufgebaut, was aber noch einiges an Erweiterungen benötigt. Schau Dir das mal an, vielleicht siehst Du dann, was noch zu tun ist.
Daten sollten nur über die Formulare gepflegt werden. Auswertungen dann über Abfragen.
Das Erfassungsformular für Bewegungen muss natürlich noch ausgebaut werden:
Zum Beispiel wird wahrscheinlich eine Suchfunktion für Artikel über Nummer und Bezeichnung nötig, weil man ja nicht immer die Artikelnummer kennt, wenn man eine Bewegung erfassen möchte
Da jeder Artikel an nur einem Lagerort liegt, wird dieser zugesteuert, so wie er im Artikelstamm hinterlegt ist. Das ist eigentlich unüblich, aber wenn die Lagerorte fest sind, ist das so. Änderbar dürfen die zugesteuerten Daten in der Bewegungsmaske natürlich nicht sein. Soll heißen: Artikel werden nur in der Artikelmaske, Lagerorte nur in fmLagerorte und Bewegungsarten nur in fmBewegungsarten gepflegt.
Wichtig ist noch die Eingaben zu überprüfen: Abgänge müssen negativ sein, Zugänge positiv. Sonst sind keine korrekten Bestandsabfragen möglich. Aber das sagte ich ja schon. Dazu habe ich in der Bewegungsmaske mal das Bestandsfeld eingebaut, wo der Bestand immer aktuell angezeigt wird. (DomSumme-Funktion in den Eigenschaften des Feldes)
 

Anhänge

Werbung:
Zurück
Oben