Office: (Office 2007) Formular zur Verknüpfung von Datensätzen bei m:n Beziehung

Hallo Accessler,

nach einiger Zeit versuche ich mal wieder mein Glück mit Access, leider nur mit mäßigem Erfolg trotz tagelanger Suche im www. Ich habe mir eine kleine Finanzverwaltungs DB erstellt. In der werden von Zeit zu Zeit Kontoumsätze per Datenimport (csv Datei der Bank, mit kleinem Umweg über Excel) in eine Tabelle tblUmsaetze geladen.

In der Tabelle tblRechnungsdaten erfasse ich Rechnungen mit einigen Details wie RNr. Datum Rechnungssteller, usw.

Zunächst habe ich versucht die Datenbank mit einer 1:1 Beziehung zwischen tblRechnungsdaten und tbl Umsaetze zu erstelllen. Das ist auch halbwegs gelungen, aber nun wollte ich mehr und stehe vor folgendem Problem:

Die tblRechnungsdaten und tblUmsaetze stehen in meiner neuen Version in einer m:n Beziehung. Es könnten mehrere Kontoumsätze zu einer Rechnung gehören (z.B. Ratenzahlung) und es könnten mehrere Rechnungen zu einem Kontoumsatz (z.B. Sammelüberweisung) gehören.

Nun habe ich die Daten in zwei Tabellen vorliegen und möchte im frmRechnungen auf einen Button klicken und dann öffnet sich weiteres Formular mit allen Umsätzen als Datenblatt und ich kann in dem Formular den zur Rechnung gehörenden Umsatz suchen und per klick, z.B. auf die ID oder in die Zeile den Datensatz mit der Rechnung verbinden.

Das möchte ich umgekehrt natürlich auch im Formular Umsatz mit den Rechnungen machen können.

Ich bin allerdings nicht in der Lage das umzusetzen...!

Als kleines Bonbon wäre es noch super, wenn das Kombifeld Projekt / Objekt im Formular frmUmsaetze nicht leer sein würde sondern die verfügbaren Projekte/Objekte der Tabelle auch zeigen würde.

Aber immer schön eines nach dem Anderen.

Bitte nicht über das doppelt gemoppelte Konstrukt aus Projekt/Stichwort und Hauptkategorie/Unterkategorie wundern. Das ist den vorhandenen Daten geschuldet und man könnte auch Umsatz und Rechnung mit Hauptkategorie/Unterkategorie aus der gleichen Tabelle versehen. DAs bekomme ich aber noch weniger hin und müsste dazu auch noch die vorhandenen Daten entsprechend konvertieren.


Meinen Entwurf ohne Daten hänge ich mal dran.

Wäre toll wenn mir jemand mit dem Zaunpfahl winken könte ;-)

Vielen Dank für eure Unterstützung im Voraus

:)

 

\@Heidegeist2000
Allgemeines Beispiel anbei.
gruss ekkehard

 

Vielen Dank für die schnelle Hilfe. Leider ist es noch nicht das was ich eigentlich suche.

Ein ähnliches Ufo wie in dem Beispiel habe ich in meine frmRechnun bzw. frmUmsatz bereits integriert, damit man den zugeordneten Datensatz sehen kann.

Aber wenn ich die Datensätze noch nicht miteinander über die m:n Tabelle tblUmsatzRechnung verbunden habe, möchte ich das mit einem Button machen, der mich auf ein Formular in Datenblattansicht (Tabelle) führt. Dort möchte ich dann aus allen Datensätzen den passenden suchen und per Klick auf den Datensatz mit dem passenden in die tblUmsatzRechnung eintragen.

Ist das halbwegs verständlich oder kann ich das irgendwie besser beschreiben?

Gruß
Heidegeist

 

Hast Du mal im Code Archiv gesucht?
Es gibt da eine Beispiel DB von mir, in der ich zwei verschiedene Möglichkeiten zeige, wie man m:n Relationen relativ handlich verwalten kann.
Die aktuellste Version ist nicht im allerersten Beitrag ...

 

Im Code-Archiv gibt es weitere Vorschläge:
Demo-Datenbank - Darstellung und Datenpflege von m:n Datensätze über Kontrollkästchen
Grundlagen - SQL ist leicht (7) - Verwendung einer m:n-Beziehung

 

Die Datenbanken und Beispiele habe ich mir angesehen, aber leider bin ich damit nicht weiter gekommen. Das ist schon ein Stück weit anders als die Lösung, die mir vorschwebt. Vielleicht ist der Weg von den Beispielen zu meiner Vorstellung garnicht mehr weit, aber ich bringe es nicht zustande.

Ok. Mal anders. Zur Vereinfachung nehmen wir mal an ich habe einen Umsatz im Formular "frmUmsaetze"
und und möchte aus den 1000 Rechnungen die passende heraussuchen und mit dem Umsatz verbinden.

Dazu muss ich die 1000 Rechungen in einer übersichtlichen Tabellendarstellung z.B. mit einer Rechnungsnummer oder einem Namen durchsuchen. Ein Kombifeld halte ich hier für zu unübersichtlich und unflexibel.

Bei dem häufig benutzten Beispiel Lehrer / Fach, ist das auf Grund der überschaubaren Anzahl an Fächern und Lehrern mit Kombifeldern lösbar, aber ich habe halt auf beiden Seiten viele Einträge.

Vielleicht kann es noch jemand einem dummen Menschen wie mir erklären.

Ansonsten schon mal vielen Dank an alle die sich die Mühe machen hier so fleißig zu lesen und zu schreiben.

Ich bin immer frustriert und beeindruckt zu gleich, wenn ich sehe wie die Profis hier einfache Beispieldatenbanken zaubern, die genial und für mich unerreichbar sind und wahrscheinlich in wenigen Minuten entstanden sind.

Hut ab vor dieser Kunst.

 

Beipiele hinken ja des öfteren ...

Aber Dein Beispiel mit dem Umsatz und den Rechnungen, da will mir partout nicht in den Sinn, was das mit m:n Relationen zu tun haben soll.

Im Falle von Bewegungsdaten ergeben sich solche m:n Beziehungen ja bei der Aufnahme.
Bestellungen stellt so eine Relation zwischen Kunden und Bestelldetails dar.
Dafür braucht es imho keine besondere Oberfläche.

Anders ist es, wenn Stammdaten in solchen Beziehungen zueinander stehen.
Die müssen übersichtlich visualisiert und leicht zugeordnet werden können.

Artikel haben Lieferanten.
Und Lieferanten liefern Artikel.
Wenn es Lieferanten gibt, die mehrere Artikel im Angebot haben und es gleichzeitig Artikel gibt, die von mehreren Lieferanten zu beziehen sind ...
Dann muss zwischen die beiden eine Tabelle als m:n Relation.
Und diese Zuordnung muss intuitiv bedienbar und übersichtlich sein.

In .Net Anwendungen gibt es ja das CheckedListView, welches ich in dieser Hinsicht sehr gut geeignet finde.
In VBA gehört das leider nicht zum Standard der Steuerelemente und das entsprechende ActiveX-Control ist etwas sperrig zu administrieren.
Na ja, wenn es denn nicht passend für Dich ist, dannhoffe ich, dass Du etwas findest, was Deinen Ansprüchen genügt.

 

Technisch:

Gibt es da auch einen Plan für eine Auswahl?

Einen Plan kann man formulieren und z.B. in eine Filterung überführen.

"Würfeln" könnte man aber auch programmatisch.

 

Hallo Hans-Christian,

Liegt an der m.E. falschen Begrifflichkeit von "Umsatz". Sinn macht es, wenn
es "Zahlungen" sind.

@heidegeist2000
Für mich bedeutet Umsatz den Netto-Rechnungsbetrag.
Zum Finden von passenden Rechnungen muss man wissen, welche Informationen
der Buchungssatz einer Zahlung hergibt. Ein gebräuchliches Verfahren ist da die
Verwendung abhängiger Kombifelder (Kunden -> Rechnungen).

gruss ekkehard

 

Das ist so ein Tot-Modell, das in bestimmte und vmtl. falsche Denkrichtungen führt.
Eine Rechnung würde man auf Basis von Leistungen (Arbeit, Artikel, Material) erstellen. Umsätze/Zahlungen wären dann die Wertstellungen dieser und somit von diesen abhängig.

 

\@Ekkehard:
Wie Eberhard schreibt: Zahlungen hängen an Rechnungen und zwar n:1.
Keine Spur von m:n ...

 

Hallo Hans-Christian,
Sehe ich nicht so.
Es gibt Kunden, die bekommen z.B. Rechnungen in kurzen Abständen und
zahlen turnusmässig mit einem Betrag für mehrere Rechnungen.
Und es gibt Kunden, die zahlen in Raten für eine Rechnung.
Für mich ist das n:m; - Rechnungen -> ZahlungenZuRechnungen

 

Servus Ekkehard,

wir haben auch Zahlungseingänge wie von dir beschrieben:
> Kunde zahlt eine Rechnung mit einer Zahlung
> Kunde zahlt eine Rechnung mit mehreren Zahlungen (Ratenzahlung)
> Kunde zahlt mehrere Rechnungen mit einer Zahlung

 

OK, räume ich ein - mehrere Rechnungen mit einer Zahlung, das gibt's.

Trotzdem bleibt die Frage offen:
brauche ich dafür eine m:n Relation?

Wie sieht das denn in der Praxis aus?
Der Kunde bezahlt mehrere Rechnungen mit einer Zahlung.
Wie macht er das?
Er schreibt die fraglichen Rechnungsnummern in das Betreff-Feld des Überweisungsbelegs.
Das ist freilich nicht gerade das, was man "normalisiert" nennen könnte - im Gegenteil.


Wie auch immer der Zahlungseingang in die (Access) Datenbank kommen mag ... da ist Handarbeit gefragt, um der jeweiligen Rechnung (=Sollstellung) die jeweilige Gutschrift gegenüberzustellen.

Und jetzt gibt es ja prinzipiell zwei Möglichkeiten:
a) ich erfasse die Zahlung als ein Beleg und lege anschliessend zwei oder mehr Belege in der m:n Tabelle an, in der ich die eine Zahlung den mehreren Rechnungen zuordne
oder
b) ich splitte die Zahlung und lege direkt die mehreren Eingänge - jeweils als n:1 - Sätze zur passenden Rechnung an, erspare mir die m:n Tabelle und habe es in der Auswertung (offene Posten) deutlich einfacher.

Ich würde immer für Lösung b) plädieren.

 

Servus Hans-Christian,

in der Praxis ist es so das man spätestens mit der Zahlung
ein Zahlungsavis erhält auf dem die gezahlten Rechnungen
mit Rg.-Nr. und Rg.-Betrag aufgelistet sind.

Dann reicht ein Endlosformular wo man den Kunden aussucht
und darunter seine offenen Rg.-Posten aufgelistet sind.
In jeder Zeile gibt es eine Checkbox "Zahlung erhalten".
Diese wird dann angeklickt und somit ist die Zahlung verbucht.
Hierzu braucht es keine m:n Tabelle.

Interessant wird folgender Praxisfall:
Der Kunde zahlt eine Rechnung über 5.000 € mit 5 Eingangszahlungen:
Rechnung:
Rg. 12345 vom 01.02.2020 über 5.000 €

Zahlungen:
Zahlung am: 28.02.2020 über 1.000 €
Zahlung am: 31.03.2020 über 1.000 €
Zahlung am: 30.04.2020 über 1.000 €
Zahlung am: 31.05.2020 über 1.000 €
Zahlung am: 30.06.2020 über 1.000 €
Um das abzubilden wird dann doch eine m:n Relation benötigt.