Office: Summen

Hallo Access-Profis,

ich bin hier relativ neu und bräuchte eure Hilfe bei einem wahrscheinlich relativ simplen Problem. Habe eine Rechnungsdatenbank erstellt in der ich folgende Tabellen verwende. Artikel, Kunden, Rechnungen und Rechnungsdetails. Über Abfragen verbunden sind nun Kunden und Rechnungen als auch Rechnungsdetails und Artikel. Die Rechnungsdetails holen sich die Artikeldaten über die DLookup funktion, damit sich bei nachträglicher Preisänderung bereits getätigte Rechnungen nicht mehr ändern. Soweit so gut! Im Formular lässt sich jetzt alles gut eintragen und im Unterformular gibts auch ne schöne Summe aller Artikelpositionen (berechnet). Nun zu meinem Problem. Ich hätte gerne, dass sich beim Schließen des Formulars nun dieser berechnete Gesamtwert des Auftrages in ein bereitstehendes Tabellenfeld in der Rechnung einträgt, damit man in einer separaten Übersicht die Auftragsvolumina erkennen kann! Zur Zeit hab ich das folgendermaßen gelöst: Me!Volumen =nz([Abf_Rechnungsdetails Unterformular].Formular!Gesamtsumme). Es zeigt mir wunderbar die momentane Summe an, die wird allerdings danach nicht in der Tabelle gespeichert! Hoffe ich habe mich halbwegs klar ausgedrückt. Kann mir jemand helfen? Ich bin für jede Hilfe dankbar.

Danke für eure Zeit und Mühe,
lg Stevie

 

gefährlich, gefährlich...

Ok, guter Ansatz. Und was, wenn sich die z.B. technischen Details (verbessertes Nachfolge-Modell) ändern?

Eigentlich ist eine Verknüpfung der Rechnungs-Details zu den Artikel-Details so gut wie nie sinnvoll, weil die Rechnungs-Details besser eine statische Kopie zum Zeitpunkt der Rechnungs-Erstellung sein sollten. Dann ist gewährleistet, daß nachträgliche Änderungen am Artikel-Stamm sich in keinster Weise auf die bereits fakturierten Rechnungen durchschlagen.

Heißt so in etwa, Du hast:

Code:

+--------------------------------------------------+
| Hauptformular (einzel)                           |
| Rechnungskopf (Kunde, Datum usw. )               |
+-----+--------------------------------------------+
|     | Unterformular (endlos)                     |
|     | Rechnungsposten 1 .. x                     |
|     +--------------------------------------------+
|     | Rechnungs-Summe                            |
+-----+--------------------------------------------+

Warum? Was sich einmal berechnen läßt, läßt sich immer wieder berechnen. Ein rechnendes Feld in der Abfrage ist da wahrscheinlich sinnvoller, als ein statisches Feld in der Tabelle.

Und für Umsatz-Übersichten solltest Du eh genug ID-Variationen in den verschiedenen Tabellen haben, um Teil-Summen über diverseste Bereiche bilden zu können, sei es Kunde, Rechnung, Warengruppe, Artikel, ...

Du arbeitest doch durchgehend mit Abfragen und nie direkt auf den Tabellen, oder? ;-)

Gruß, Michael

 

Danke ersmal für die schnelle Hilfe! Ich arbeite ausschließlich auf Abfragen, da kannst du unbesorgt sein *g*. Deine Schematik trifft auch auf meine DB zu. Vielleicht habe ich mich bei der Summe nicht klar ausgedrückt. Ich habe sehrwohl in der Abfrage berechnende Elemente, diese errechnen allerdings nur Zeilenweise die Summe im Unterformular, zB Artikel: Tisch, Einzelpreis: 100,00, Stück: 5, USt: 20% mit DLookup aus einer Artikelabfrage geholt, errechnet werden Gesamtpreis netto und brutto in der Abfrage. Als Summe über die gesamte Rechnung habe ich im Fuß des Unterformulars ein ungebundenes Textfeld. Diesen Wert, sprich das jeweilige Auftragsvolumen kann ich mir auch im Hauptformular anzeigen lassen, allerdings speichert es mir diesen Wert nicht. Ich weiß wohl, dass es jedesmal berechnet wird, zwinge aber den Nutzer der DB über einen Speicherbutton zum Schließen einer Rechnung. In diesem Button hätte ich gerne eine Funktion eingebaut, die das aktuelle Volumen der Rechnung (Unterformular) im Hauptformular speichert. Somit hat man in der Rechnungskopftabelle diesen Wert - der wird im Weiteren für eine Übersicht herangezogen, welche Aufträge welchen Wertes in diesem Monat noch zB zu bearbeiten, offen oder in Verrechnung sind. Im Ernst habe ich bis jetzt dieses Rechnungsmodell als Angebotserstellung gedacht. Und hierfür ist es wichtig, dass man pro Monat nicht über einen gewissen Betrag kommt, allenfalls ist die zeitgerechte Auftragsabwicklung gefährdet (Tischlerei mit Kapazitäten von zB XXX/Monat)! Ich hoffe ihr/du kannst mir folgen.

Ich danke für eure/deine Hilfe.
Lg Stevie

 

Ich wäre im Übrigen auch zufrieden mit einer Lösung, die mir aktuell den Wert eines Angebots errechnet, anstatt aus einem berechnenden Textfeld zu übernehmen falls das den Accessästhetikern unter euch mehr beliebt?

Jede Hilfe wird dankend angenommen, obwohl nicht zwingend verstanden (zB das mit den ID-Variationen???)

Lg Stevie

 

Und wenn ich schonmal so unverschämt fragen stellen darf, vielleicht kann mir jemand bei meinem nächsten Problem helfen. Ist wahrscheinlich nur ein Syntaxproblem, aber trotzdem. Wie oben beschrieben hole ich mir in meiner Angebotslegung die Kundendetails für den Angebotskopf mit der DLookup-Funktion aus einer Abfrage. zB Rechnungs- und Lieferadressen! Das funktioniert wunderbar, im Übrigen auch im Unterformular bei den Preisen und USt-Sätzen. Bezüglich des Kunden - er sollte mir auch die Anrede und Titel mit eben dieser Funktion in den Angebotskopf übernehmen, tut er aber nicht. Das Problem ist, dass es eigene zugrundeliegende Tabellen mit Anrede und Titel gibt, die als Nachschlageoption im Dropdownmenü bei der Erstellung eines Kunden aufscheinen! zB. Anr_ID: 1, Anrede: Herr, Anr_ID: 2, Anrede: Frau. Die DLookup-Funktion auf die Abfrage nach den Kunden liefert mir jetzt statt Herr - 1 und statt Frau - 2. Einfach herrlich - muss ich da jetzt sowas wie einen InnerJoin basteln? Bin mit meinem Latein am Ende!

Danke für die Mühe mir zu helfen als auch für den Aufwand meine komplizierten Erklärungen zu verstehen *g*.

Lg Stevie

 

Ok, dann mach ich in spanisch weiter, aber beschwer Dich dann nicht, daß Dir das alles spanisch vorkommt... ;-)

Das mit den IDs wird Dir, bei konsequenter Umsetzung, eine Menge Fragen beantworten und eine Menge Aufwand ersparen. Das mehrfache Speichern von Informationen (Anreden, Summen, ...) wird dadurch dann auch überflüssig.

Nehmen wir mal ein rudimentäres Gerüst:

tbl_Kunden
Kunde_ID: Autowert / Zufall
KundeName: Text
[...]

tbl_Rechnungen
Rechnung_ID: Autowert / Zufall
Rechnung_KundeRef: Zahl / Long
RechnungDatum: Datum
[...]

tbl_Rechnungsposten
Posten_ID: Autowert / Zufall
Posten_RechnungRef: Zahl / Long
ArtikelAnzahl: Zahl / Double
ArtikelName: Text
ArtikelPreis: Zahl / Double
[...]

Beziehungen
tbl_Kunden.Kunde_ID 1:n tbl_Rechnungen.Rechnung_KundeRef
tbl_Rechnungen.Rechnung_ID 1:n tbl_Rechnungsposten.Posten_RechnungRef

Deine Abfrage über die Rechnungsposten kann jetzt um das rechnende Feld "PostenSumme" (=ArtikelAnzahl*ArtikelPreis) erweitert werden. Aber soweit ich es verstanden habe, hast du das auch schon so realisiert.

Eine weitere Abfrage könnte jetzt aber z.B. eine Summe bilden über "PostenSumme", wobei die Abfrage noch "gruppiert" wird, z.B. nach "Posten_RechnungRef". Damit hättest du alle Rechnungen mit ihren Gesamtsummen.

Wenn Du stattdessen nach einer Artikelnummer gruppierst, bekommst du die Umsätze nach jedem Artikel aufgeteilt. Oder eine Gruppierung nach Kundennummer zeigt Dir die Umsätze pro Kunde.

Da kommst Du aber natürlich um Abfragen, die mehr als eine Tabelle umfassen, nicht mehr herum. Alle Tabellen, also tbl_Kunden, tbl_Rechnungen und tbl_Rechnungsposten, müßten dann in einer Abfrage kombiniert werden. Der Entwurfs-Editor zeigt dabei aber auch schon prima die Verbindungslinien passend zu den Beziehungen an.

Und so löst Du auch das Problem mit der Anrede: In der Kunden-Tabelle hast Du nur eine Referenz (die ID) auf die passende Anrede, nicht aber die Anrede selbst. Die Abfrage umfaßt dann sowohl die Kunden-, wie auch die Anreden-Tabelle und im Ergebnis hast du die zum jeweiligen Kunden passende Anrede.

tbl_Anreden
Anrede_ID: Autowert / Zufall
AnredeText: Text
[...]

Und in tbl_Kunden dann noch das Feld
Kunde_AnredeRef: Zahl / Long

Und die Beziehung
tbl_Anreden.Anrede_ID 1:n tbl_Kunden.Kunde_AnredeRef

Eine Test-Abfrage könnte dann ergeben:

Code:

Kunde_ID   KundeName   Kunde_AnredeRef   Anrede_ID   AnredeText
123456     Thomsen     -246803           -246803     Herr
357924     Schneider   483650            483650      Frau
[...]

Und wenn dann jemand die Anrede "Herr" in "Senor" ändert, dann schlägt sich das auf alle Kunden durch, die diese Anrede benutzen. Niemand muß mehr einzeln alle Kunden durchackern, um die Anreden anzupassen.

Gruß, Michael

 

Ich bedanke mich herzlich, ich glaube dadurch hast du den Nagel auf den Kopf getroffen. Auf die Idee ne Abfrage auf ne Abfrage zu machen bin ich natürlich nicht gekommen.

Vielen Dank, lg Stevie

 

Hab das mit ner Abfrage auf ne Abfrage ausprobiert und es funktioniert tadellos. Das mit der Gruppierung war mir einfach nicht geläufig.

Wenn ich in diesem Zuge vielleicht gleich nochmal eine Frage anhängen darf?
Es geht um selbige Datenbank, sprich die zur Erstellung von Angeboten. Als nächster Schritt wäre geplant aus ausgewählten Angeboten Aufträge zu machen. Weiters soll es aber auch möglich sein Aufträge so zu erfassen, ohne ein dazugehöriges Angebot vorliegen zu haben.

Meine Herangehensweise wäre wie folgt (ich bitte um Korrektur falls das konzeptionell zu umständlich ist - wie würdet ihr das machen):
Zwei gleiche Tabellen, tbl_Rechnungen und tbl_Rechnungszeile, nur eben für den Auftrag. Nun würde ich gerne einen Button in dem Angebotsformular haben, mit dem sich der aktuelle Datensatz, inklusive Unterformular, in die Auftragstabellen schreiben lässt? Das muss wohl irgendwie mit der Recordset Methode funktionieren. Weiters hätte ich aber auch gerne einen Button im Auftragsformular mit dem sich Angebote nach zB Nummer und Nachname durchstöbern lassen und wiederum einfügen lassen. Das wird wohl die gleiche Methodik sein? Ist das überhaupt sinnvoll oder gibts bessere/alternative Lösungen?

Ich bin für eure Hilfe wirklich sehr dankbar.
Lg Stevie

 

Ich würde jetzt nicht behaupten wollen, daß es der einzig wahre und sinnvolle Weg ist, den man dort beschreiten kann, aber es wäre der, den ich auch benutzen würde (und auch schon mehrmals habe).

Letztendlich brauchst Du eine Abfrage, die dir alle Datensätze zurückliefert, die die ID des aktuellen Angebots haben, was i.d.R. nur einen einzigen Datensatz zurückliefern sollte, weil ansonsten das Konzept der ID irgendwie brüchig wäre... ;-) Des weiteren bräuchtest du noch eine Abfrage, die Dir alle Angebots-Posten zurückliefert, die zur ID des aktuellen Angebots gehören.

Es gibt hier grundsätzlich 2 Möglichkeiten: a) eine Abfrage mit Parametern, die zur Laufzeit gesetzt werden oder b) eine Schleife direkt in VBA, die mit FindFirst, FindNext usw. arbeitet.

Im zweiten Schritt hilft Dir dann .AddNew weiter, mit dem Du einen neuen Datensatz erzeugst und dann die Felder mit Werten füllen kannst. Die Online-Hilfe gibt da, wenn ich mich recht entsinne, auch ganz gute Beispiele. Alternativ kannst Du natürlich auch eine SQL-Abfrage zusammenbasteln und per docmd.runsql abfeuern...

Und so füllst du neue Datensätze in tbl_Rechnungen und tbl_Rechnungsposten mit den Werten aus tbl_Angebote und tbl_Angebotsposten. Dabei mußt Du ja nicht zwingend alle Felder übernehmen, mußt aber ggf. andere neu berechnen. Das würde alles die eine, zentrale Routine hinter dem Button machen.

Ein "Such"-Formular ist, je nach User-Freundlichkeit, ein beliebig kompliziertes Konstrukt. Ich habe mir vor längerem mal eine Methode zusammengebastelt, die vielleicht nicht mehr ganz "state of the art" ist, aber für mich den Vorteil der relativ leichten Anpaßbarkeit (im VBA allerdings) hat:

Ich habe ein Endlos-Formular, das auf einer Abfrage "über alles" basiert. Im Fuß-Bereich des Formulars habe ich Textfelder, in die man Such-Werte eingeben kann. Ggf. sind dort auch Checkboxen usw. vorhanden.

Mit einem "Suchen"-Button setze ich dann eine WHERE-Klausel zusammen, mit der man dann die Datensätze des Formulars filtern kann. Also ganz grob so:
Feld1 (Suche Stadt): Dar
Feld2 (Suche Nachname): Me
könnte dann als WHERE-Klausel ergeben:
f = ([stadt] like 'Da*') AND ([nachname] like 'Me*')
Mit einem 2. Button kann man den Filter dann auch wieder zurücksetzen, wenn man wieder alle Datensätze sehen will.

(Nur dran denken: Texte in ' einschließen, Zahlen nicht. Und bei Wildcard-Suchen das LIKE statt des = benutzen.)

Ein unsichtbarer Button, der quer über den Detail-Bereich gelegt ist, öffnet ein weiteres Formular, in dem dann die Details zum angeklickten Datensatz bearbeitet werden können.

Wenn ich das richtig verstehe: Den Datensatz kopieren und dann einige Felder anpassen? Access bietet eine "Datensatz kopieren" Funktion, bei der ich dann aber per VBA den dann entstanden Datensatz direkt anpassen würde. Aber das ist Situations-bedingt unterschiedlich...

Gruß, Michael

 

Ich bin mit VBA ein wenig vertraut und benutze einige Funktionen wie DLookup und if mit schleifen. Versteh mich nicht falsch, ich bin dir für deine Hilfe sehr dankbar, leider kann ich mit deiner letzten Antwort nicht allzuviel anfangen. Könntest du mir Starthilfe geben wie man in besagtem Fall die Recordset Methode ungefähr anwendet?

Lg Stevie

 

Ich sollte vielleicht erwähnen, dass es nicht notwendig ist den Datensatz zu kopieren, es genügen mir die Feldinhalte, die ich nach Notwendigkeit auch verändern kann. Eventuell ist hier ne dlookup funktion auf den aktuellen Datensatz mit Recordset zum übertragen auf ein neues formular möglich?

 

Genau richtig... Und deswegen dürfte .AddNew Dein Freund werden. ;-)

Schau Dir mal die Online-Hilfe zu .AddNew an, dort das Beispiel. Ich habe jetzt gerade kein Access zur Hand, aber wenn ich mich recht entsinne, ist das Beispiel dort recht umfassend von "dim db as database, dim rs as recordset" usw. über "rs.addnew" bis hin zum "rs.update". Das kannst Du Dir ja rauskopieren und als Basis für Änderungen benutzen.

Letztendlich erzeugst Du mit .addnew eine neue Zeile in einer Tabelle mit zunächst mal leeren Feldern. Diese kannst Du dann einzeln mit Werten füllen (z.B. rs("feldname2")=me!feldname1.value) und dann zum Schluß mit .update speichern.

Grober Ablauf könnte sein:

Code:

rs1 auf tbl_angebote, rs2 auf tbl_angebotsposten
rs3 auf tbl_rechnungen, rs4 auf tbl_rechnungsposten
findfirst auf rs1 über Rechnungs-ID
rs3.addnew
rs3 Felder mit Werten aus rs1 oder Berechnungen füllen
rs3.update
ID merken
rs2.findfirst über Rechnungs-Ref, bookmark setzen
(Schleife, solange Datensatz gefunden)
  rs4.addnew
  ID als Ref setzen
  rs4 Felder mit Werten aus rs2 oder Berechnungen füllen
  rs4.update
  rs2.findnext
(Ende Schleife)

Alles jetzt aus'm Stegreif und ungetested, übelster Pseudo-Code, aber dürfte eigentlich als Grundlage für den weiteren Aufbau schonmal helfen, hoffe ich...

Was ich aber dringendst empfehlen würde: Du kannst die rs auch, statt direkt auf die Tabellen, auf eine SQL-Abfrage setzen. Wenn du Dir also passende SQL-Abfragen bastelst, die z.B.

Code:

rs1sql = "SELECT * FROM tbl_Rechnungen WHERE (Rechnung_ID=" & me!rechnung_id.value & ");"
rs2sql = "SELECT * FROM tbl_Rechnungsposten WHERE (Rechnung_Ref=" & me!rechnung_ref.value & ");"
[...]

lauten, kannst Du, ohne groß Datensätze "suchen" zu müssen, direkt mit movefirst, movenext arbeiten. Denn das "suchen" hat die WHERE-Klausel schon für Dich im Vorfeld übernommen. Hilfe dazu findest Du beim passenden Stichwort: dbopenrecordset war's, glaube ich, könnte aber auch dbopendynaset sein.

Aber schau Dir erstmal in Ruhe das addnew-Beispiel an und bastel Dir in einer Test-Umgebung vielleicht mal irgendwas, um ein wenig damit herumzuexperimentieren. Dann dürfte recht schnell einiges klarer werden.

Gruß, Michael

 

Ich bekomms einfach nicht hin. Das Problem ist, es funktioniert schon nicht mal an einer kleinen Versuchsdatenbank. Kannst du mir dabei vielleicht helfen, wäre echt supernett von dir. Habe als Beispiel eine kleine DB mit tbl_Ursprung und tbl_Ziel angehängt, darauf 2 Abfragen und 2 Formulare. Formular Abf_Ursprung beinhaltet einen Button woraufhin der Feldinhalt des aktuellen Datensatzes (hier mal nur ein zB Namensfeld) in das Formular Abf_Ziel übertrage werde soll.

Ich werd dabei ganz irre - wie auch immer ich meinen rs schreibe er kann mein feld nicht finden!

Danke herzlichst,
lg Stevie

PS: schreibe normalerweise auf 07, habe hier aber nur 03 zur Verfügung.

 

Ach jetzt darf ich wieder so nen Anhang nicht schicken - ich versuchs mal mit ner gezippten Version!

 

So, ich habs doch irgendwie geschafft, mit dem einfachen Beispiel:

Private Sub Befehl4_Click()
On Error GoTo Err_RecordSet
Dim db As Database
Dim rs1 As Recordset
Dim rs2 As Recordset
If IsNull([Ursprung]) Then Exit Sub
Set db = CurrentDb()
Set rs1 = db.OpenRecordset("Abf_Ursprung", dbOpenDynaset)
Set rs2 = db.OpenRecordset("Abf_Ziel", dbOpenDynaset)
rs1.FindFirst "[Ursprung_ID] = " & [Ursprung_ID]
If Not rs1.NoMatch Then
rs2.AddNew
rs2![Ziel] = rs1![Ursprung]
rs2.Update
rs2.Close
rs1.Close
MsgBox ("In Aufträge kopiert!")
DoCmd.Close
Dim stDocName As String
Dim stLinkCriteria As String
stDocName = "Abf_Ziel"
DoCmd.OpenForm stDocName, , , stLinkCriteria
End If
Exit_RecordSet:
Set rs1 = Nothing
Set rs2 = Nothing
Set db = Nothing
Exit Sub
Err_RecordSet:
MsgBox ("Fehler")
Resume Exit_RecordSet
End Sub

Oder ist hier was einzuwenden?
Ich hab jetzt schon Angst wenn ich das in die eigentliche DB implementieren will. Das mit dem UF wird wahrscheinlich noch um etliches schwieriger.

Lg Stevie