Office: (Office 2013) und parallel Neubau DB

Bewegungsdaten, ja.

Bitte bzgl der Buchung bei einer Abfrage bleiben - das ja/nein-Feld zeigt nur an, ob etwas gebucht wurde.

Für Lieferung und Verkauf werden die Belege durchnummeriert, sind also immer verschieden.
Die Positionen pro Beleg werden jeweils von 1 ab nummeriert.

Die Unterscheidung, dachte ich, mache ich mit einem Kreuzchen oder Kombifeld deutlich, wo ich anklicke/eingebe, ob es eine Lieferung oder ein Verkauf ist.
Damit wären dann alle Belege in einer Tabelle möglich.

Ob der Faktor -1 mit der Menge multipliziert wird, hängt von diesem Kreuzchen/Eingabe ab.
Dafür brauche ich eine Formel, zB WENN...
__

Bin noch bei deiner DB...

bzgl qryZweiFelderEinGangAusgang
Die Formel MengeEingang: Wenn([Faktor]*[menge]>0;[menge]) und MengeAusgang: Wenn([Faktor]*[menge]

 

Hallo,

da braucht es kein Wenn. Wer in einer Datenbank Wenn braucht hat was falsch gemacht.
Das geht immer automatisch, datensatzbezogen. Dafür gibt es Beziehungen.

Die haben keine Verbindung. Das ist ja auch eine Beispieldb, da sind einfach beispielhafte Sachen drin, das brauchst Du nicht.

Da braucht es auch keine Aktualisierungsabfrage, das wird in der Abfrage direkt berechnet.
Bei dem Beispiel gibt es auch keinen Buchungsvorgang.

Du denkst noch in Excel. Die Summenfunktion in Access summiert einfach Spalten.
Code:

Ergibt die Summe der Spalte Rechenmenge.
Code:

Ist die Summer der Spalte Faktor und Menge als Multiplikation.

Im Anhang findest Du mal Deine umgebaute DB. Da kannst Du mal knabbern dran. Die felder die ich für überflüssig halte habe ich mal entfernt.
Das Feld BuchungK in den Ufos kann man ausblenden und nur zur Kontrolle (eventuell mit extra Formular) einblenden. Damit wird das sicherer gemacht gegen Fehlbedienung.
In der Abfrage findest Du die Bestandsrechnung.

 

Aaaaaah !!!
Danke für deine Antworten - Mir ist gerade eine ganze Girlande aufgegangen !!! *Smilie

*gespannt die DB anguck...* *Smilie

 

Etwas schlanker... ggg
Diese Art der Trennung hatte ich bei meinen Alternativen überhaupt nicht mehr dabei, da ich davon ausging, Lief + Verk sollen in eine Tabelle.

Aaalso...
Ich nummeriere es mal durch, weil wenn ich jetzt eine deiner Antworten auf eine falsche Frage beziehe, ist die Verwirrung komplett *wink.gif*

1) Gebucht wird per Kreuzchen, Rückbuchung ebenso.
Wie es hinterlegt ist, habe ich noch nicht ganz verstanden, muss ich noch mehr gucken.

2) Das Hauptformular zeigt komischerweise nur den Beleg 1 an und ist "stocksteif", offeriert auch keinen neuen Datensatz.
Hat vermutlich seinen Sinn - verstehe es aber noch nicht g

3) Hm, Unterschied zwischen ZuAb_Unterformular und ZuAb_Unterformular1...

4) Hauptformular besteht aus 2 Registerformularen.
Register Lieferungen
mit dem Lieferungen_Unterformular - und das beinhaltet das ZuAb_Unterformular1
Register Verkäufe
mit dem Verkauf_Unterformular - mit dem ZuAb_Unterformular

5) Ist das Hauptformular evtl nur eine Art Phantom, das man ausblenden könnte, weil man nicht direkt damit arbeiten (Daten eingeben) kann ?
Und es dient nur als Container für die anderen beiden Unterformulare ?

6) Oder bekommst du beim Hauptformular die Registerformulare angezeigt und ich habe damit ein Problem, weil Acc2013 es falsch anzeigt ?
(Früher hatte ich auch mal Registerformulare und verknüpfte Formulare gemacht, die Registerformulare zeigten sich auch entsprechend an.)

7) In den beiden ZuAb_Unterformularen ist vermutlich die Verknüpfung das Entscheidende, dass die BelegNr in die jeweilige Spalte eingetragen wird - warum genau, verstehe ich aber noch nicht ganz.

8) Bzw: Wo steht, dass die BelegNr je nach Lieferung oder Verkauf entsprechend in der Tabelle ZuAb in die jeweilige Spalte LieferungID oder VerkaufsID geschrieben wird ?

9) Oder ruft man es durch die richtige Wahl des Formulars auf ? Dass damit automatisch die BelegNr wg der Verknüpfung in die richtige Spalte geschrieben wird ?

10) Der Zusammenhang von VerkaufsBelegNr und ZuAbID kommt mir irgendwie schräg vor bzw erkenne da noch nicht so richtig das Bild "Beleg und Positionen".

11) Irritierend ist, warum im Lieferungen_Unterformular kein Auotwert eingefügt wird, wenn ich mit Enter über das Feld LieferungID hinweg weiter klicke.
Und dass nach dem Enter im Feld LieferBelegNr der Eintrag in diesem Feld gelöscht wird, und der Cursor dort bleibt statt in das ZuAb_Unterformular zu springen.
Der Cursor im Unterformular springt nach Eingabe eines Datensatzes nicht in den nächsten.
Und er springt nach Eingabe von Position 1 zwar zu dem nächsten Feld aber im nächsten Datensatz.
Komisch, aber ist wohl eher ein anderes Problem und hat ja mit dem Aufbau der DB nichts zu tun.

12) Abfrage mit BuchMenge: Summe([Menge]*[faktor]*Abs([BuchungK])) ist verständlich, aber die Schritte davor fehlen mir.

Hmm.
Also so ganz habe ich den Ablauf Schritt für Schritt noch nicht vor meinem geistigen Auge, aber es rumpelt... *Smilie

Ich suche und suche nach was... mehr Formeln oder Extras... - aber wie du sagtest, manches ist per Zuteilung geregelt und läuft damit wohl automatisch im Hintergrund schon ab.

PS: die Buchung per Kreuzchen sieht zwar zugegeben fein aus - insbesondere auch, weil die Rückbuchung damit so einfach geht *gefällt mir*
Aber bei vielen, vielen Artikeln, die am Monatsende erst verbucht werden - da bin ich immer noch von einer Aktualisierungsabfrage überzeugt = 1 Klick und zigzig Artikel verbucht.

 

Hallo,
1) Musst Du noch kucken

2) das Hauptformular hat keine Aufgabe, das ist nur der Container für das Register und die Ufos, das kannst Du genau so gut auch mit 2 Formularen machen 1 für Lieferung und eins für Verkauf. Das ist ja nur ein Vorschlag.
Den Datensatzzeiger unten habe ich nur vergessen zu entfernen.

3) ZuAb_Unterformular ist für Verkauf (Standardwert für Bewegungsart_f=2) und ZuAb_Unterformular1 ist für Lieferung (Standardwert für Bewegungsart_f=1)

4, 5, 6) siehe 2

7, 8, 9) Das wird über die Dateneigenschaft verknüpfen von/nach gemacht. Die Übertragung erfolgt automatisch. Schaue es Dir an, dann erkennst Du die Zusammenhänge. Und eine Belegnummer wird nicht übertragen, die Belegnr ist frei von Dir vergebbar. Es wird nur das Schlüsselfeld übertragen.

10) da gibt es keinen Zusammenhang VerkaufsBelegNr ist frei wählbar und ZuAbID ist nur das Schlüsselfeld.

11) da wird nichts gelöscht, das ist ein neuer Datensatz mit leeren Feldern. Der Autowert wird erst eingetragen wenn in eine anderes Feld etwas eingetragen wird.

12) da gibt es keine Schritte davor, die Abfrage ist alles.

Zum PS.
Das kannst Du trotzdem mit einer Aktualisierungsabfrage machen. Die Tabelle mit den Lieferungen und Verkäufen erhält ein Ja/Nein Feld das Du zur Aktualisierung aller BuchungK Felder nutzen kannst.

Und bedenke bitte, dass das ja erst mal ein einfacher Vorschlag ist. Da gibt es sicher noch Verbesserungspotential.

 

Ein riesengroßes Danke für deine Antworten, Zeit, Anregungen und Korrekturen !!

Auch wenn ich vielleicht bis sicher noch mal nachfragen muss, so habe ich jetzt zumindest Input, mit dem ich weitermachen und -probieren kann ! *Smilie

Bin am Starten mit einem neuen Nachbau...

Dir noch einen schönen Abend
skys

 

ups, gleich doch noch eine Frage:

wäre es nicht durch die Tabellenbeziehungen möglich, Menge und BuchungsK in der Tabelle Artikel zu lassen (wie im Montage-Bild im Anhang) ?
Durch die Beziehungen müsste es doch egal sein, da auch dort ansprechbar und berechnen möglich ?

 

Hallo,
die Frage zeigt mir, dass Du es immer noch nicht ganz verstanden hast.
Beide Felder haben bei den Artikeln nichts zu suchen, es wäre auch sinnlos.
Die Artikeltabelle ist eine Stammdatentabelle die sich nur durch neue Artikel verändert. Mit dieser Tabelle wird nichts gebucht, da kann auch nichts gebucht werden. Angenommen Du hast 500 Artikel dann können ja in der Tabelle "tbl_ZuAb" mehrfach der Artikel geliefert oder verkauft sein. In der Artikeltabelle gibt es jeden Artikel aber nur 1x, wie willst Du das in der Artikeltabelle buchen, bzw. was soll das für einen Sinn machen ?

Und die Menge, was soll die Menge im Artikel ?
Den Bestand hast Du ja jederzeit in der Abfrage.

 

Einen Artikel gibt es, durch Primärschlüssel abgesichert, in der Artikeltabelle genau einmal.
Könntest Du abgeleitet davon mit genau einer Menge und einer Buchung dazu auskommen?
Dass ein Artikel dann über die Zeit und bei mehreren möglichen Lieferanten auch nur genau einen Preis und einen Rabatt hat, ist in der Praxis schlecht vorstellbar.

 

Hallo,
anknüpfend an die Hinweis von Eberhard auch die Frage:
Kann ein Artikel nur ein Lieferant haben ?
Und das auch in der Zukunft ?

Die Fragen hätten auch von mir schon früher kommen müssen.

Man könnte auch überlegen, Lieferungen und Verkauf in eine Tabelle zusammenzufassen. Ich habe die getrennt, weil nicht klar ist, was jeweils zu einer Lieferung und einem Verkauf erfasst werden soll.
Wenn das nur das Datum und eine Belegnummer ist, würde eine Tabelle reichen (mit Kennzeichen).

 

Hallo gpswanderer und ebs17,

Verstehe dich - aber ganz so schlimm ist es nicht *Smilie

Ich hatte lediglich wieder vergessen, dass es ja eine andere Menge ist als das, was ich bisher unter "Menge" laufen hatte (der Bestand).

Logisch, sind mehrere Mengen, etc. Ich war gedanklich einfach noch bei der alten DB-Struktur hängen geblieben.

Da ich immer auch noch vergleiche und hinterfrage und nicht einfach nur deinen DB-Vorschlag kopiere, kann mir so eine Falle mal passieren.
Ich möchte es eben gedanklich nachvollziehen können und wenn ich wieder so eine Frage habe, dann selbst auf die richtige Lösung kommen. Die muss sich aber erst mal einprägen...*redface

Ja.

Naja, im Moment kann 1 Artikel nur 1 Lieferanten haben - die Wahrscheinlichkeit ist auch groß, dass es so bleibt.
Denke, es macht auch Sinn, da mit einem anderen Lieferanten vermutlich auch die Artikelbezeichnung, Preis, Packung sich ändern könnte.
Wechselt der Lieferant, gibt es eben auch eine neue Artikelnummer.

Ansonsten bräuchte ich ja noch eine n:m Beziehung - überlege gerade, was ich da als sinnvolle Tabelle dazwischen schalten könnte und denke, da würde dann eine Tabelle "Bestellung" Sinn machen.
Aber brauche ich nicht. Als Übung evtl mal noch mache, wenn ich mit der DB ganz fertig bin. Habe aber noch genug andere Fragen auf meiner Liste.

Das hatte ich ja zwischendurch gemacht, weil ich ebs17 Vorschlag so verstanden hatte.

Erfasst wird bei einer Lieferung:
Datum, LieferungsNr, BelegNr, Positionen, ArtNr, Menge, etc und entsprechend auch bei einem Verkauf. Und das passt im Moment ja auch.

Mal sehen, ob ich es nun noch mit den Abfragen, Formularen und Berichten alles so hinbekomme, wie ich möchte.

Vielen Dank euch und Grüße
skys

 

Hallo,

ich hänge schneller als gedacht... *GRRRRR*

Kreuzabfragen habe ich evtl sogar hinbekommen - was Menge und Summen und Artikel angeht. Stell ich aber mal hinten an.

Ich hänge bei den Formularen...

Bsp das Formular für Zugänge/Lieferungen.

1) In der Muster-DB habe ich bei Datensatzherkunft jeweils dies:

PS: verstanden *Smilie
und

Ich verstehe im Moment nicht mal, warum - denn wenn ich auf meine Formulare gehe, dann habe ich die Select-Auswahl nicht bei Datensatzherkunft stehen, aber es zeigt mir die Daten dennoch an.
Ist das also nur "Nummer sicher" oder wieso ? Hat doch sicher einen Sinn ?

2) Bei den Musterformularen geht es nur um die Eingaben:
Lieferung_ID, Lieferdatum, LieferBelegNr (tbl_Lieferungen) und
ArtNr_f, Menge, BuchungsK - AAAH und Bewegungsart ! (Standard 2 und nicht sichtbar *gefunden* *Smilie)

3) Bleibt noch die Frage bzgl Zugang_f und Abgang_f in der tbl_ZuAb.
*suche* Wann und wo werden die (automatisch) ausgefüllt, wenn nicht händisch über ein Formularfeld ?
AAAAH - ich ID-Dusselchen ! *Smilie

So, nun habe ich zwar lange für das Posting gebraucht, aber 2 Antworten selbst gefunden *Mann, was liege ich manchmal breit auf der Leitung !*

Aber Frage 1 weiß ich noch nicht.

Grüße
skys

 

Hallo,

1) was bedeutet denn:

im Zusammenhang mit dieser einfachen Abfrage:

Außerdem bekomme ich den Faktor noch nicht mit einberechnet.
Dachte, ich könnte es so machen, dass es mit Eingabe im Formular dann schon richtig in der tbl_MengeZuAb als Minuswert eingetragen wird - aber das geht wohl gar nicht ?
Dachte, das bekomme ich auch ohne Abfrage hin.

2) Warum wird hier nicht der richtige Faktor (-1) genommen, obwohl bei dem Abgangsformular als Bewegungsart_f 2 = Faktor -1 eingetragen ist ?

(Ich stelle die Abfrage in der Entwurfsansicht zusammen, nicht per SQL)
Vermutlich stimmt etwas nicht mit dieser Formel:

PS s. unten (Tabellenangabe vergessen !)

3) hm - hier habe ich gerade meine Frage verloren, aber da stimmen die Formeln wohl auch nicht:

und

4) Kreuzabfrage Nr 1

Glaube, wäre ganz ok, wenn nicht die Formel noch falsch wäre... *redface
(Mit Pivot in Excel komme ich klar, aber hier hakt es noch.)

Es fehlt der Faktor und die Summe von Lieferung und Verkauf. Vielleicht:
Bestand = SUMME ( tbl_ZuAb.MengeZuAb der Lieferungen + (ABS(tbl_ZuAb.MengeZuAb der Verkäufe)*[tbl_Bewegungsart_f.Faktor]) )

Aber wie definiere ich tbl_ZuAb.MengeZuAb der Lieferungen ?
Fällt mir nur eine WENN-Funktion ein (wenn < 0) aber zum einen verhaspel ich mich da und zum anderen vermute ich, das geht kürzer, oder ?

5) Kreuzabfrage Nr 2

Ist nicht besser, außerdem habe ich als Spaltenüberschrift , 1, 2 - also auch nicht das Wahre.

Viele Grüße
skys

PS zu 2)

Klappt *Smilie

6) Hm, Holzweg *frown.gif*

mit Fehlermeldung:

Hm ??

So listet die Tabelle nur die Abgänge:

7) Abfrage nach Abgängen und Zugängen klappt (glaub):

 

Hallo,
bitte zeige mal ein Bild des aktuellen Beziehungsfensters.

Was willst Du mit den Kreuztabellenabfragen darstellen ?

 

Hallo gpswanderer,

Beziehungen etc angehängt.

"Zugänge" auflisten und "Abgänge" auflisten funktioniert.
Sind beides neue Spaltennamen...

...von denen ich dachte, ich könnte damit in der Kreuztabellenabfrage rechnen - aber irgendwas passt nicht.

Fehlermeldung:

Muss ich Zugang und Abgang erst in eine extra Tabelle füttern, damit ich damit weiter rechnen kann ?

Im Prinzip möchte ich mit der Kreuztabellenabfrage etwas ähnliches wie die tbl_ZuAb darstellen, aber mit den richtigen Zugängen (Pluswerte) und Abgängen (Minuswerte).

Außerdem bekomme ich es noch mit dem Faktor nicht hin (oberes Posting)