Office: Artikelverwaltung in Access

Guten Tag,

ich habe von meinem Chef die Aufgabe bekommen eine Datenbank mit Access zu erstellen, in der Artikel verwaltet werden können.
Ich sollte also Artikel anlegen können (ca. 200 Stück) und diese mit einer Artikelnummer, Anfangsbestand, Kategorie, Zugänge, Abgänge, Abgänge (kostenlos), Abgänge (fehlend) versehen können.
Weiterhin sollen die Mitarbeiter Zugänge und Abgänge in einer Eingabemaske (Formular?) eingeben können, sodass sich der Bestand automatisch aktualisiert.
Zu guter letzt soll der Ausdruck einer Übersichtstabelle über alle Artikel möglich sein.

Gibt es da vielleicht jemand eine Vorlage, oder kann mir sagen, wie ich das am besten angehe?

Vielen Dank schonmal!

Gr.
Florian

 

Ja, ja... So sind Chefs manchmal... ;-)

Klingt, so weit erstmal, nicht nach Raketentechnik.

Vorlagen zu dem Thema (Auftragsverwaltung, Lagerverwaltung, ...) findest Du im Netz wie Sand am Meer. Ich glaube, sogar der DB-Wizard in Access selbst vietet etwas in der Art an.

Das Problem mit den "Vorlagen" ist, daß man meist mehr Arbeit und Zeit damit verbringt, sie an die eigenen Vorstellungen anzupassen, als man gebraucht hätte, das ganze Ding selbst zu erstellen.

Mal so aus dem Stegreif:

Du brauchst eine Tabelle "tbl_Artikel" (oh, welch Überraschung!), in der sich die Stammdaten der Artikel befinden. Stammdaten sind die Daten, welche sich später nicht mehr oder nur eher selten ändern. Dazu gehören sowas wie Artikelnummer, Bezeichnung, Preis, ... (ok, bei einigen Firmen hab ich den Eindruck, daß der Preis eher zu den Bewegungsdaten statt zu den Stammdaten gehört... ;-) )

Dann brauchst Du eine Tabelle "tbl_Bewegungen", in der sich die ganzen Zu- und Abgänge der ganzen Artikel finden. Das ganze muß 1:n mit den Artikeln verknüpft werden. Benutz dazu ein eigenes ID-Feld als "primary key" in tbl_Artikel (ich nehm dazu gerne auto/zufall) und ein entsprechendes long-Feld in tbl_Bewegungen als Referenz. Benutz besser nicht(!) die Artikelnummer als 1:n Feld, da diese "nach außen" geführt wird. Für Beziehungen nimmt man besser ein rein "internes" Feld, daß der User auf den Formularen in besten Fall nie zu sehen kriegt.

Bau auf jede der beiden Tabellen erstmal eine Abfrage qry_Artikel und qry_Bewegungen mit jeweils allen Feldern. Benutz aber nicht "*", sondern doppelklick die Feldnamen einzeln der Reihe nach durch. So kannst Du z.B. dann auch gleich die Sortierung für ein Feld einstellen, was mit "*" nicht gehen würde. Dann bau Dir noch eine qry_Artikel_Bewegungen, die beide Tabellen zusammenfaßt.

Jetzt kannst Du Dir 2 Formulare basteln: Zuerst ein "einfach" Formular frm_Artikel für die Stammdaten der Artikel. Dann noch ein "endlos" Formular frm_Bewegungen für die Bewegungen. Dann schlußendlich bettest Du das frm_Bewegungen als Unterformular in den Detailbereich von frm_Artikel ein. Der Wizard hilft Dir dabei, die Verknüpfung von ID (Hauptformular) und Referenz (Unterformular) herzustellen.

Jetzt solltest Du ein Formular haben, wo Du im Haupt-Teil die Stammdaten der Artikel bearbeiten kannst und im Unterformular die gesamten Bewegungen des Artikels einsehen und bearbeiten kannst.

Jetzt kommt noch qry_Artikel_Bewegungen ins Spiel: Bastel Dir noch einen Bericht, der darauf basiert und stelle unter "Ansicht - Sortieren und Gruppieren" den Kram so ein, daß nach Artikel-ID gruppiert, nach Artikel-Nummer sortiert und jeweils Gruppen-Kopf und -Fuß angezeigt wird. Vor dem Gruppen-Kopf oder nach dem Gruppen-Fuß würde ich empfehlen, einen Seitenwechsel zu aktivieren.

Im Groben und Ganzen war's das auch schon. Was Du im Einzelnen dann noch an weiteren Formularen brauchst, damit die Mitarbeiter unfallfrei ihre Einträge machen können, ohne z.B. die Stammdaten zu zergrützen, wirst Du dann selbst entscheiden müssen. Und dabei wird Dir auch so ziemlich keine Vorlage helfen können.

Frei nach dem Pareto-Prinzip: 80% der Arbeit ist in 20% der Zeit geschafft, aber die letzten 20% der Arbeit, der Feinschliff, nehmen dann die restlichen 80% der Zeitz in Anspruch.

Gruß, Michael

 

Vielen Dank schonmal.

Ich habe jedoch noch ein Problem. Ich verstehe noch nicht ganz, wie ich das lösen kann, damit sich, sobald ich im Formular "Bewegungen" einen Zugang bzw. Abgang verbuche, auch der Bestand
in der Tabelle "Artikel" verändert.

Ich habe eine Tabelle "Artikel" mit folgenden Feldern:

Art.Nr.
Beschreibung
Kategorie
Anfangsbestand
Zugang
Abgang

Und eine Tabelle "Bewegungen" mit folgenden Feldern:
Art.Nr.
Zugang
Abgang
Datum

Und eine Tabelle "Kategorien" mit folgenden Feldern:
ID
Name

Artikelnummer von "Artikel" und "Bewegungen" stehen in einer 1:n Beziehung, genauso wie Kategorie und ID.

Desweiteren habe ich ein Formular erstellt mit allen feldern der Tabelle "Artikel" um neue Artikel einpflegen zu können.
In dieses Formular habe ich das Formular Bewegungen eingebettet.

Des weiteren bestehen zwei Abfragen. Zum einen "Artikel" und und zum anderen "Bewegungen", um später im Bericht eingrenzen zu können.

Was muss ich tun, damit sich die Bewegungen, die ich im Formular einfüge auch auf die Tabelle "Artikel" auswirken?

Danke!

 

Normalerweise wird das Feld "Bestand" in dieser Konstellation im Laufe des Geschäftsjahres nicht verändert.

. o O ( Huh? Was? Wie? immer der gleiche Bestand? Das geht doch nicht... )

Sieh das Feld "Bestand" als das Feld an, was bei der Inventur am Jahres-Anfang mit einem Wert gefüllt wird. Im Laufe des Jahres wird der Bestand nur rechnerisch per Abfrage ermittelt:
aktueller Bestand = Anfangsbestand + Summe aller Zugänge - Summe aller Abgänge
alternativ natürlich auch, wenn mit +/- Bewegungen gearbeitet wird:
aktueller Bestand = Anfangsbestand + Summe aller Bewegungen

Erst am Jahres-Ende bei der nächsten Inventur wird dann ermittelt, ob der rechnerisch ermittelte Bestand und der tatsächlich gezählte Bestand übereinstimmen. Abweichungen werden dann mit einer Buchung "Inventur-Differenz" ausgeglichen.

Das erspart Dir Updates des "Bestand" Felds über's Jahr, die vielleicht ja auch mal schief gehen können (Absturz der Software oder was auch immer) und dann völlig irrsinnige Werte ausgeben könnten.

Gruß, Michael