Sich verkürzende Nachschlageliste

[walsch.rene]

Sehr geehrte Damen und Herren,

es ist mir nicht gelungen, meine Suche (siehe Betreff) so zu formulieren, dass ich das (mit Sicherheit schon vorhandene) Thema finde. Statt Rüge erbitte ich einfach einen passenden Link zur geeigneten Antwort.

Der Fall:

Tabelle tbLeistungen: Leistung ID (Autowert), Leistung (Text), ZahlungNo (Zahl)
Tabelle tbZahlungen: ZahlungID (Autowert), LeistungID (Zahl), RechnungID (Zahl) (1:n mit tbLeistungen verknüpft)
Tabelle tbRechnungen: RechnungID (Autowert), Rechnungsdatum (Datum), Rechnungssumme (Währung)
Formular fmZahlungen (Datenquelle: tbZahlungen) in der Datenblattansicht mit nur einem Element, einem Nachschlage-Kombinationsfeld

Über dieses Formular sollen Leistungen Rechnungen zugeordnet werden. Über das Kombinationsfeld wird in der Tabelle tbRechnungen nachgeschlagen und die RechnungID aus tbRechnungen als RechnungID in tbZahlungen abgelegt. Angezeigt wird die Rechnungssumme. Soweit banal.

Ich möchte aber erreichen, dass eine bereits einer Leistung zugeordnete Rechnung nicht mehr im Nachschlage-Kombinationsfeld auftaucht (die Nachschlageliste also immer kürzer wird, je mehr Rechnungen ich Leistungen zuordne). Auch das ist nicht weiter schwer: Über die Datensatzherkunft des Nachschlage-Kombinationsfelds kann ich mittels einer entsprechenden Abfrage nur die Rechnungen anzeigen lassen, deren RechnungID noch nicht in tbZahlungen auftaucht.

Das funktioniert, hat aber einen entscheidenden Nachteil: Bei bereits zugeordnete Rechnungen wird der Inhalt des Kombinationsfeldes (die Rechnungssumme) im Formular fmZahlungen nicht mehr angezeigt. Man sieht zwar, dass der jeweiligen Leistung eine oder mehrere Zahlungen zugeordnet sind, aber eben nur als weißes (leeres) Kombinationsfeld (anstatt der Rechnungssumme).

Wie lautet die Lösung?

Vielen Dank,
René

[database]

Hallo,

ganz klar scheint mir deine Datenaufbereitung da nicht zu sein.

Man ordnet keiner Rechnung Leistungen zu sondern ertellt eine Rechnung und wählt zu verrechnende Leistungen aus. Die Leistung definiert sich ihrerseits beispielsweise durch den Leistungstext also die Beschreibung, die Einheit der Leistung und deren Einzelpreis.
Die ID der Rechnung kann dann z.B. zusammen mit der ID der Leistung, der zu verrechnenden Anzahl, dem angewandtem Steuersatz und dem Leistungsdatum (gem. österr. Rechtslage) in einer Zwischentabelle (zwischen Rechnung und Leistung gespeichert werden.
Somit kann jederzeit festgestellt werden, welche Leistung mit welcher Rechnung abgerechnet wurde, bzw. welche Rechnung eine bestimmte Leistung in Rechnung gestellt hat.
Rechnungssummen werden zu dem nicht gespeichert sondern immer bei Bedarf durch Abfrage berechnet.

In der Tabelle Zahlungen hat m.E. die LeistungsID nichts verloren, da nicht eine einzelne Leistung bezahlt wird sondern der auf der Rechnung ausgewiesene Betrag - daher zieht hier richtigerweise die RechnungsID.
Werden Teilzahlungen geleistet, beziehen sich diese Zahlungen ausschließlich auf die gesamte Rechnung und nicht auf die verechneten Leistungen.

Man sieht zwar, dass der jeweiligen Leistung eine oder mehrere Zahlungen zugeordnet sind ...

Das Problem entstammt vermutlich der nicht richtigen Zusammensetzung der Tabellenfelder (Normalisierung) und einer ev. nicht richtigen Abfragedefinition.

Wie lautet die Lösung?

Diese Frage wage ich nicht pauschal zu beantworten, in der Regel beginnt aber die Lösung mit einem funktionierendem, normalisierten Datenmodell.
Abläufe, die dann auf der Datenbank via Formularen durchgeführ werden SOLLEN orientieren sich ausschließlich am Datenmodell,
das seinerseits bereits bei der Planung - den benötigten Gegebenheiten angepasst - erstellt wird. Ein recht komplexes Thema aber OHNE dem geht's eigentlich nicht.

HTH
Peter

[DF6GL]

Hallo,

lösbar wäre es auf diese Art:


Dem vorhandenen Kombi ALLE Datensätze in der Datensatzherkunft liefern.

Weiteres ungebundenes Kombi einbauen, das jetzt nur die DS anzeigt, "die nicht in ...sind ".
Die Breite des Feldes soweit reduzieren, bis nur der Aufklapppfeil noch zu sehen ist. Mit "In den Vordergrund" und Sperren des 1. Kombis kann der "Pfeil" auf den des ersten Kombis gelegt werden, so dass optisch das Ganze nur als ein Kombi erscheint.
Mit dessen  Afterupdate-Ereignisprozedur den ausgewählten Wert dem ersten Kombi zuweisen.

[René Walsch]

An Access-Guru:

Vielen Dank. Vielleicht hätte ich statt eines konkreten Beispiels (Leistungen, Zahlungen, Rechnungen) besser ein abstraktes gewählt (A, B, C). Es handelt sich hier nicht um klassische Buchhaltung, aber der reale Hintergrund meiner DB würde hier zu weit führen. Das Datenmodell ist jedenfalls seit Jahren bestens geeignet für meine Zwecke.

An Access-Gott:

Deinen Ansatz habe ich noch nicht ganz verstanden, werde aber in diesem Sinne ein bisschen rumbasteln. Ich melde mich dann. Vielen Dank für Deinen Tipp.

Beste Grüße,
René 

[database]

Hallo,

Das Datenmodell ist jedenfalls seit Jahren bestens geeignet für meine Zwecke

Ich würde es so bezeichnen, dass die Handhabung der Gegebenheiten bestens geeignet ist für deine Zwecke - was ja der auslösende Grund dafür ist, dass man eine Applikation so gestaltet, wie man sie braucht.
Dass die Zusammenstellung der Tabellendaten nicht stimmt und es daher zu Ungereimtheiten im Fall eines benötigten Informationsgewinnes kommt bleibt jedoch eine Tatsache.
Das hat aber mit den von dir erwähnten Zwecken nichts zu tun - das bitte nicht zu werwechseln.
Konstruktive Kritiken an einem Datenmodell sollen ja keineswegs dazu führen die Business-Logic dahinter zu verändern. Das heißt, wenn du es für deine Zwecke
so benötigst Leistungen einer Rechnung zuzuweisen, dann soll es auch so bleiben!
ABER nicht normalisierte Datenmodelle führen früher oder später IMMER zu Problemen.

... besser ein abstraktes gewählt (A, B, C)...

Kann natürlich auch sein, dass ich in meiner Antwort diese - nach deinen Angaben - weniger realen Bezüge zu tief analysiert habe.
Mag sein, dass durch die 'realen' Bezugsnamen Hintergrund und Zweck nicht klar erscheinen - was jedoch nicht das Problem ist,
die Auffälligkeit besteht auch bei vollständigen, abstrakten Angaben.

Was Franz dir vorgeschlagen hat ist eine passable, gangbare Möglichkeit, dein Problem (sorry, das deiner Datenbank) zu umgehen.

Greets