Office: (Office 2013) und parallel Neubau DB

Hallo,

parallel zum Umbau hier nun der Neubau der DB.
Und hier nochmal, was ich von euch schon an Tipps dazu habe:

gute Idee und hoffentlich richtig umgesetzt (s. Bild)

Stimmt wohl alles - und: ich kenne mich mit dem IIf-Ausdruck eh nicht aus.
Wie gesagt, stammt nicht von mir.

Im Datensatz mit den Mengen wird die Menge mit dem Faktor multipliziert (Zu/Abgang per Kombi auswählen, statt dem Kreuzchen) und man hat automatisch das richtige Vorzeichen. Dieses berechnete Feld über den Artikel gruppiert gibt stets automatisch aktuell den Bestand aus. Alles automatisch, ohne das Vorzeichen beachten zu müssen.

Da bin ich noch am werkeln und umsetzen...
Also noch eine Tabelle Bewegung mit den 2 Feldern und das Kombifeld...

Soweit schon mal Danke und schönen Sonntag
skys

:)

 

Hallo,
Hallo,
- wo ist die Tabelle für die Bewegungsart (Zugang/Abgang) ?
- was willst Du mit der Menge in der Tabelle "tbl_Artikel" ?
- was bedeutet die Position in der Tabelle "tbl_ZuAb" ?
- die Tabelle "tbl_Gesamt" halte ich für überflüssig, das Datum gehört direkt in die Tabelle "tbl_ZuAb"
- wieso bestehen die Tabellen Lieferant, Lagerort und Mwst nur aus einem Feld ?

 

Hallo gpswanderer,

bin am werkeln, kommt noch.

Die ist für den aktuellen Bestand.
(jeweils plus verbuchter Zugänge bzw minus verbuchter Abgänge. Erst nach der Buchung verändert sich der aktuelle Bestand)

Beispiel: Am 1.1.17 kommt eine Lieferung, bestehend aus 3 Belegen (zB weil 3 Firmen). Auf jedem Beleg stehen mehrere Positionen (1 Obsthändler liefert Äpfel, Birnen, Gurken = 3 Positionen)

Hatte ich auch einen Moment gedacht und gemacht, dann aber wieder geändert.
Da 1 Artikel auf mehreren Belegen und auf 1 Beleg mehrere Artikel stehen können. Ergo brauche ich für n:m noch eine Zwischentabelle.

Wobei ich mir hier noch unsicher bzgl der Belege bin. Das hat sich geändert, weil nun Zu- und Abgänge (und deren Belege) in einer Tabelle sind.

Salopp gesagt: es war so ;)
Hatte auch überlegt,. ob ich sie zusammenlegen kann, aber denke, dass nicht.
Im Prinzip könnte man noch weitere Felder rein nehmen (zB Lieferant-Tel-Nr), ist im Moment aber nicht wichtig.
Lagerort und MwSt gibt es auch nicht viele Zusatzinfos, deshalb nur ein Feld.
MwSt hätte ich sonst noch als Feld in die tbl_Artikel genommen.
Lagerort theoretisch auch möglich wäre, aber der könnte sich ja auch mal ändern (Lager voll?).

 

Hallo,

das ist ersatzlos überflüssig, der Bestand ergibt sich vollkommen automatisch nach einer Buchung über die MengeZA.

Dann ist das Datenmodell ohnehin falsch. Und wird auch nicht ganz so einfach, Zugänge und Abgänge können in dieser Tabelle nicht zusammengefasst werden, zumindest nicht so einfach. Hier wird eine extra Tabelle für die Bestellung benötigt.
Sind jetzt die Bestellungen für die Zugänge oder die Abgänge ?
Wenn die Tabelle Positionen für die Zugänge enthält, wie soll das dann gehen für die Abgänge?
Du solltest als erst mal erklären, wie das mit den Abgängen gedacht ist, wie ist das dann mit den Positionen ?
Das ist alles noch reichlich verworren.
Erkläre die Zusammenhänge mal genauer.

Die 1-Feld Tabellen sind so unbrauchbar. Ich hatte auch nicht vorgeschlagen die zusammenzulegen, das würde auch keinen Sinn machen.
Aber die Tabellen sollten einen Primärschlüssel (Autowert) bekommen, Texte sind als PS ungeeignet.
LieferantID
LieferantName

LagerOrtID
Lagerort

MwstID
MwstSatz

 

Also zuerst die Zusammenhänge (ich weiß schon, warum ich die alte DB auch umbauen will ;) :

Beispiel: ein Kiosk...
Von 5 Händlern werden 30 Artikel eingekauft.
Zugang: Ein Lieferschein (= 1 Beleg) kann 10 verschiedene Artikel (= 10 Positionen) beinhalten.
An einem Tag können mehrere Lieferungen (Lieferscheine) kommen.
Abgang: Beim Verkauf gibt es pro Rechnung ebenfalls Positionen - so wie bei einem Kassenbon. (zB weil am Ende des Monats wichtig ist, wer was und wie viel gekauft hat).
In die DB kommt nicht, was bestellt wurde, nur was geliefert wurde.

Sowohl die Zugänge als auch die Abgänge werden nach der Aufnahme per Formular erst noch kontrolliert. Nach dem "ok" bzw am Monatsende werden sie erst zu-/abgebucht (= Buchungs-/Aktualisierungsabfrage.)
Und erst nach der Buchung ändert sich der Bestand der vorhandenen Artikel.
Deshalb auch einmal die Menge in der tbl_Artikel (= aktueller gebuchter Bestand) und die MengeZA in der tbl_Zu-/Abgänge, wo die Menge des Zu- bzw Abgangs aufgenommen, aber noch nicht verrechnet wird.
__

Es ist das 1.x, dass ich Texte als PS verwenden wollte.
Meine Überlegung war, dass ich damit nicht rechnen möchte und die Eindeutigkeit erhalten bleibt.
Da man mit einer ID auch nicht rechnet, obwohl es eine Zahl ist, dachte ich, das müsste gehen.

Daher die Interessensfrage, warum geht es mit Texten nicht ?
Die DB hat deswegen bis jetzt noch nicht reklamiert.
__

Und Frage zu der Faktor -1 Tabelle:
Habe jetzt die tbl_Bewegungsart erstellt
PS Feld Bewegungsart_ID
Feld Faktor

Bewegungsart_ID (allerdings im Moment noch wieder mit Text, da es eindeutig wäre: Zugang, Abgang - und evtl Rückbuchung Zugang, Rückbuchung Abgang)

Selbst wenn ich den Feldtyp auf Zahl wechsle - bin ich am überlegen, mit welcher Tabelle ich sie in Beziehung setze.
Ich denke, da der Faktor sich auf Zu/Abgang bezieht, müsste ich sie mit der tbl-ZuAb verbinden - aber wie...
n:m:
Faktor 1 (Zugang) - viele Belege (Zugänge)
viele Belege (weil Zu- und Abgänge in 1 Tabelle) können sowohl Faktor 1 als auch -1 haben

oder 1:n mit dem Fremdschlüssel Bewegungsart_f in der tbl_ZuAb ?

 

Hallo,
Schlüsselfelder müssen ja vergleichen und ein Vergleich mit einer Zahl ist immer besser/schneller als Textvergleiche. Außerdem vermeidet man sprechende Texte als Schlüsselfelder. Was würdest Du machen, wenn es als Lieferant 2x Meier oder Müller gibt, wie früher, Müller1, Müller2 ?
Für die Bewegungsart wird das Schlüsselfeld Faktor zwingend benötigt, denn mit dem Faktor wird gerechnet und damit automatisch das Vorzeichen (+/-) bestimmt. Da hast Du das Prinzip noch nicht verstanden.

Das machst Du einfach mit einem Ja/Nein Feld "Gebucht". Die Menge kannst Du mit diesem Ja/Nein Feld multiplizieren, dann geht automatisch nur die Menge in den Bestand ein die auch kontrolliert und gebucht wurde. Ja/Nein Feld = Ja.

Die Menge für die Summierung für den Bestand ergibt sich dann vollkommen automatisch über ein berechnetes Feld in der Abfrage:
Code:

Und diese Menge wird über den Artikel gruppiert und summiert = Bestand.
Das Feld Menge in der Artikeltabelle ist in jedem Fall überflüssig.

Aus meiner Sicht sind folgende Tabellen notwendig.

- Lieferant (ggf. auch Kunden in dieser Tabelle, (Autowert als PS, Lieferantname)
- Lagerort
- Mwst
- Lieferungen (Autowert als PS, Lieferdatum)
- Verkauf ((Autowert als PS, Verkaufdatum)
- Bewegungsart
- ZugangAbgang (FS zu Lieferungen und FS zu Verkauf entweder/oder gefüllt, FS zu Bewegungsart, Datum)

Die Tabelle "tbl_Gesamt" ist nicht notwendig, das Datum gehört direkt in die Tabelle ZugangAbgang.

Kannst Du mal die DB hier hochladen, nur die Tabellen ?
Ich benötige aber eine MDB (Access2003).

 

Das Prinzip mit dem Faktor habe ich glaub schon verstanden. Rechnen kann man ja auch mit dem Faktor in einem anderen Feld, deshalb hatte ich ihn nicht unbedingt als PS nötig angesehen.

Die Buchung wäre damit nur abhängig von dem Ankreuzen ?
Das halte ich nicht für so sinnvoll - wie schnell ist ein Kreuzchen aus Versehen gemacht oder nicht.
Das Buchen möchte ich getrennt als Aktualisierungsabfrage laufen lassen.

Und das Abs(Ja/Nein-Feld) müsste dann aber noch mit den aus den Lieferungen eingegebenen Zahlen hinterlegt sein.
Stelle ich mir nicht leichter vor.

Ich möchte die DB möglichst auch verstehen, nachvollziehen können.
Eine zu hohe Messlatte nützt mir nichts, da komme ich nicht mit.
Deshalb immer wieder betone, warum es mir um das geht, was ich frage.

Interessiert mich durchaus und hätte auch eine Abfrage grob im Kopf, wie es vielleicht sein könnte - aber vermutlich noch nicht ganz richtig.

Leuchtet mir gerade gar nicht ein.
Keine Artikel-Tabelle mehr ?

Hochladen schon, mdb auch, aber siehst ja nix und geht nur als zip.

 

Hallo,
die Artikeltabelle habe ich schlicht und einfach vergessen.

Und die Aktualisierungsabfrage muss ja auch von was abhängig sein, oder nicht ?
Du brauchst ja dann auch irgendein Zeichen/Vermerk dass etwas kontrolliert ist. Die Aktualisierungsabfrage halte ich nach wie vor für überflüssig, die bringt Dir keinen Vorteil. Die Aktualisierungsabfrage hat ja auch eine Abhängigkeit und die muss auch richtig gemacht sein und könnte auch aus Versehen gesetzt sein. Oder wie hast Du Dir das gedacht ? Auf was basiert die Aktualisierungsabfrage ?

Da muss nix hinterlegt sein, das ergibt sich automatisch über den Datensatz.

Ich wollte eine MdB zum Nachbauen, damit ich nicht alles nachbauen muss. Und aus einer Zip kann man auch wieder die MDB machen. *grins

 

Hallo,

Beruhigend *Smilie

Naja, in der alten UmbauDB sieht das für die Zugänge derzeit zB so aus - und funktioniert prima:

In der neuen DB versuche ich gerade die Berechnung mit dem Faktor einzubauen. Dh im Unterformular habe ich die Berechnung nun zwar in einem neuen Feld =[MengeZA]*(-1) aber steh dafür nun trotzdem da wie der Ochs vorm Berg.
Im richtigen Formular fehlt es. Und wie den berechneten Wert dann in die DB einspeisen, weiß ich noch nicht...

edit:
Zubuchung funktioniert (Bild Anhang) *freu*
Jetzt mal mit Abbuchung probieren - wird nicht so einfach *denk*

 

Hallo,
in der Aktualisierungsabfrage beziehst Du Dich auf das Feld BuchungsKz.
Und wenn das jemand falsch macht ?
Die Abfrage bringt Dir keinen Vorteil, Du musst Dich auch damit auf die Richtigkeit wie es jemand gemacht hat verlassen. Das ist auch nix anderes wie mein Ja/Nein Feld.

Das Feld ZugangK ist auch überflüssig.
Die Berechnung mit dem Faktor macht man in einer Abfrage und nicht im Formular. Da gibt es auch nichts einzuspeisen, die ist einfach drin.

Im Anhang findest Du das mit dem Faktor mal in einem einfachen Beispiel.

 

Vor allem habe ich bei der Zubuchung den Faktor noch nicht gebraucht - aber auf den kommt es ja an, wenn ich alles in eine Tabelle schreiben will.
Ein Kreuzchen-Feld Zugang war noch zu viel, ja.

Ui, Danke ! - Lese mich in dein Beispiel mal ein...

 

Hallo,

Du denkst noch viel zu kompliziert. Den Faktor brauchst Du zwar, aber das geht automatisch. Du hast ja eine Tabelle für die Lieferungen und eine Tabelle für die Verkäufe. Die Artikel dazu würde man in jeweils einem Unterformular eingeben. Da lässt sich dann der Faktor automatisch setzen. Da musst Du nichts eingeben, das läuft alles im Hintergrund, ganz automatisch und damit automatisch auch fehlerfrei.

Das von mir vorgeschlagene Ja/Nein Feld macht man im normalen Formular unsichtbar. Und blendest diese Feld nur ein, wenn kontrolliert wird.


Ich würde Dir ja ein Beispiel bauen, aber dazu hätte ich gern die DB mit den Tabellen.

 

edit:
Muss gerade etwas umdenken:
meine Bewegungsart entspricht deiner Vorgangsart
meine Zu-/Abgänge deiner Bewegungsart

Das rote Feld auf dem Formular finde ich gut

das muss ich noch wirken lassen... *gerade etwas verwirrt*

Brauche noch etwas, um das Beispiel im Hirn ganz intus zu haben...
__

Ich steig so schnell noch nicht dahinter, ja *grmpfl*

Ja, so will ich das an sich auch. Nur ein Haken oder Kombifeld und dann wird der Faktor mit einberechnet.

Ops - Moment, dass es kein Missverständnis gibt.
Nur in der alten habe ich für Zugang und Abgang je eine Tabelle.
Hier probiere ich es ja nur noch mit einer Tabelle für Zu-/Abgänge auf den Rat hin.

Dachte, das Feld ist dazu da, um anzugeben, ob es ein Zu- oder Abgang ist - und dann im Hintergrund das Rechnen auslöst.
Also ähnlich, wie wenn ich in Excel zB sage Wenn Feld x = angekreuzt, dann rechne mit Faktor -1, sonst nix.

Habe dir mal die (neue) DB gezippt. Aber sind noch die Text-PS drin, einfach überlesen bitte ;) Die werden in der Endfassung dann noch gegen Zahl getauscht.

 

Siehst du den Rauch auch ?
Glaube, bei mir schmoren gerade ein paar Neuronen durch... !

 

Hallo,

wo siehst Du bei mir eine Bewegungsart ? Die Tabelle heißt Bewegungsdaten.
Mit dem Ja/Nein Feld meinte ich das Feld zum Buchen.

Das verstehst jetzt Du falsch. Nur die Tabelle für die Menge ist eine Tabelle, Du musst nach wie vor Lieferungen und Verkäufe unterscheiden können. Eine Lieferung (und Verkauf) umfasst ja verschieden Positionen.
Und in die Tabelle mit den Mengen kommt eine Fremdschlüssel zur Lieferung und ein Fremdschlüssel zum Verkauf die entweder/oder gefüllt werden.

Es wird in jedem Fall gerechnet. Für das Ja/Nein Feld Buchung wird bei Nein die Menge mit 0 multipliziert, daher geht dann die Menge nicht in den Bestand ein. Beim Faktor wird entweder mit -1 multipliziert oder mit 1, damit wird sonst nix wie das Vorzeichen bestimmt.

Das Feld für die Buchung blendet man im Erfassungsmodus aus um ein versehentliches anklicken zu verhindern.