Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!

Mobiles Hauptmenü

Zwischensumme in Abfrage bzw. Formular

Begonnen von micha286, Dezember 02, 2011, 14:31:46

⏪ vorheriges - nächstes ⏩

micha286

Hallo liebe Access-Profis,

ich benötige Hilfe bei der Gestaltung einer automatisierten Berechnung von Gebühren. Die Gebühren werden zu verschiedenen Zeitpunkten (datRec) in Abschlägen beglichen (im Folgenden lngRecAbschlag) und der Betrag der letzen Rechnung (im Folgenden lngRecFinal) sich automatisch wie folgt berechnen soll:

lngRecFinal-Summe(lngRecAbschlag)

Das Problem ist dabei nun, dass die Anzahl der Abschläge nicht fix vorgegeben. Es kann also mal 2 Abschläge, mal 5 Abschläge geben. Zudem habe ich es so gestaltet, dass per Checkbox im Formular ausgewählt wird, ob es sich um die Abschlussrechnung handelt oder nicht. Dementsprechend wird die Berechnung der Gebühren beeinflusst.

Jeder Abschlag ist dabei mit einem eindeutigen Datum versehen.

Beispiel:

vorl. Rechnungssumme zum Beginn: 100 €

1. Abschlag, 01.01.2011: 20 € => lngRecAbschlag=20
2. Abschlag, 02.02.2011: 40 € => lngRecAbschlag=40
3. Abschlag, 20.02.2011: 10 € => lngRecAbschlag=10

Rechungssumme zum Abschluss: 200 €

Abschluss, 03.03.2011: lngRecFinal=200-20-40-10=140

Soweit ich das durch meine Recherchen hier im Forum und auf anderen Seiten bisher verstanden habe, müsste das eigentlich mit DomSumme gehen. Pseudo-mäßig müsste ich mir mE für die Abschlussrechnung die folgende Summe berechnen: DomSumme("RecAbschlag";"qry_Gebuehr";"datRec <" & datRec)...

Leider funktioniert das so nicht und ich finde dazu auch keine passende Lösung...könnt ihr mir weiterhelfen?

Besten Dank schon einmal und beste Grüße!
micha286

Beaker s.a.

Hallo Michael,

Bin zwar kein Profi, aber den einen oder anderen Gedanken kann ich schon beisteuern.

ZitatDie Gebühren werden zu verschiedenen Zeitpunkten (datRec) in Abschlägen beglichen (im Folgenden lngRecAbschlag) und der Betrag der letzen Rechnung (im Folgenden lngRecFinal) sich automatisch wie folgt berechnen soll:

Wenn der Prefix den Datentyp wiedergibt, halte ich das für keine gute Wahl. Es geht doch um Kohle, Asche, Penunse, um nicht  zu sagen Geld. Long Integer stellt aber keine Dezimalzahlen zur Verfügung, nimm lieber Currency.

ZitatlngRecFinal-Summe(lngRecAbschlag)3

Hier berechnest Du aber nicht lngRecFinal, sonders rechnest damit

ZitatEs kann also mal 2 Abschläge, mal 5 Abschläge geben.

Also gehören die in eine extra Tabelle, die über einen eindeutigen Schlüssel in einer Deiner anderen Tabellen, deren Struktur und Aufbau Du nicht verraten hast, verknüpft werden.

Die Tabelle mit den Abschlägen kannst Du dann zusammengehörig mit entsprechen Abfragen gruppieren, summieren oder sonst was mit machen. Für einzelne Werte reicht natürlich auch ein DSum auf die Tabelle.

hth
gruss ekkehard
Alles, was geschieht, geschieht. - Alles, was während seines Geschehens etwas anderes geschehen lässt, lässt etwas anderes geschehen. - Alles, was sich selbst im Zuge seines Geschehens erneut geschehen lässt, geschieht erneut. - Allerdings tut es das nicht unbedingt in chronologischer Reihenfolge.
(Douglas Adams, Mostly Harmless)

micha286

Hallo Ekkehard,

vielen Dank für deine Antwort! Hier ein paar Erläuterungen/Ergänzungen:

Die Gebühren sind in der Tat
ZitatKohle, Asche, Penunse, um nicht  zu sagen Geld

Mache daraus also wie du vorgeschlagen hast datentyp currency. Dann habe ich in der Tat nicht ganz sauber aufgeführt, was ich vor habe. Deswegen nachfolgend nochmal das Beispiel mit genaueren Angaben:

Die Rechnungssumme kann zu jedem Abschlagszeitpunkt variieren. Dies habe ich jetzt mit curRec festgehalten:


ZitatBeispiel:

1. Abschlag, 01.01.2011: vorl. Rechnungssumme curRec=100 €, curRecAbschlag=20
2. Abschlag, 02.02.2011: vorl. Rechnungssumme curRec=100 €, curRecAbschlag=30
3. Abschlag, 20.02.2011: vorl. Rechnungssumme curRec=120 €, curRecAbschlag=40

usw....

Abschluss, 03.03.2011: Rechungssumme zum Abschluss: curRec=200 €, curAbschlag=200-20-30-40=110


Die zugehörige Tabelle sieht wie folgt aus:


IDGebuehrPrimärschlüssel
IDRechnung_FFremdschlüssel
datAbschlagDatum des Abschlages
curRecAbschlag
blnAbschlussAbschlussrechnung Ja/Nein?

Die Checkbox blnAbschluss entscheidet also darüber, ob es sich um die Abschlussrechnung handelt oder nur ein weiterer Abschlag ausgeführt wird.

Ich hoffe, dass es so etwas verständlicher geworden ist. Bin weiterhin dankbar für jede Hilfe!

Beste Grüße
micha286

DF6GL

Hallo,

die eigentlich Frage wäre, wobei wir helfen sollen?


Die Abschlagszahlungen sind doch in der Tabelle ("tblAbschlaege" ??)  hinterlegt und können z. B. mit einem Endlosform, das im Rechnungsform als UFO eingebunden ist, dargestellt werden.

Feld "blnAbschluss" ist an sich überflüssig.  Dieser damit gekennzeichnete DS kann über einen Vergleich der Akt. bezahlten Summe mit dem Gesamtbetrag der Gebühren z. B. mittels bedingter Formatierung hervorgehoben werden.


Beaker s.a.

Hallo Michael,

Franz' Hinweise sollten schon Mal hilfreich sein.

Um da weiter zu kommen, muss ich Dir jedoch eine Frage aus Buchhaltersicht stellen.
Schreibst Du grundsätzlich Rechnungen über die geleisteten Abschlagbeträge (z.B. Abogebühren), oder schreibst Du am Ende/Anfang einer wie auch immer gearteten Periode eine Rechnung über irgendwelche Leistungen (z.B. Stromverbrauch), und forderst die Zahlung des Restbetrages ?
Im ersten Fall solltest Du dich mit Franz' Vorschlag bezüglich UFo intensiver beschäftigen.
Im zweiten Fall brauchst Du höchstwahrscheinlich auch eine HFO/UFo-Struktur, nur musst Du da im UFo die Rechnungspositionen darstellen, und die Summe der Abschläge per gruppierter Abfrage dazu holen, um den Restbetrag (Rechnungssumme - Abschläge) zu berechnen.
hth
gruss ekkehard
Alles, was geschieht, geschieht. - Alles, was während seines Geschehens etwas anderes geschehen lässt, lässt etwas anderes geschehen. - Alles, was sich selbst im Zuge seines Geschehens erneut geschehen lässt, geschieht erneut. - Allerdings tut es das nicht unbedingt in chronologischer Reihenfolge.
(Douglas Adams, Mostly Harmless)

micha286

Hallo Ekkehard,

danke für deine Antwort. Zu deinen Punkten:

Zitatoder schreibst Du am Ende/Anfang einer wie auch immer gearteten Periode eine Rechnung über irgendwelche Leistungen (z.B. Stromverbrauch), und forderst die Zahlung des Restbetrages ?

Ja :) Eine HFO/Ufo Struktur habe ich auch bereits. Prinzipiell funktioniert auch alles, bis auf die von dir angeführte gruppierte Abfrage:

Zitatmusst Du da im UFo die Rechnungspositionen darstellen, und die Summe der Abschläge per gruppierter Abfrage dazu holen, um den Restbetrag (Rechnungssumme - Abschläge) zu berechnen.

Das funktioniert leider nicht wie gewünscht, da jeder Abschlag rein theoretisch halt auch die finale Rechnungssumme über den Restbetrag sein könnte.

@DF6GL
ZitatFeld "blnAbschluss" ist an sich überflüssig.

sehe ich daher nicht so. Irgendwie muss ich ja kenntlich machen, dass ich keinen weiteren Abschlag sonder eine finale Rechnung erstellen möchte (also die gesamte Rechnungssumme abzgl. aller vorher geleistete Abschläge in Rechnung stellen möchte).

Könnt ihr mir weiterhelfen? Oder sollte ich von dem Gedanken Abstand nehmen und die Abschlusszahlung vielleicht im Haupformular einbauen? Das wäre vielleicht umsetzbar, nur von der logischen Struktur her nicht so schön.

Besten Dank und beste Grüße
Michael

DF6GL

#6
Hallo,

"sehe ich daher nicht so."


Meine Sicht:   Sobald eine Rechnung  über  den Restbetrag (oder auch mehr)  (den man ja akt. aus den vorangegangenen Rechnungen ermitteln kann )  ausgestellt  wird, dann handelt es sich hierbei um eine "finale" Rechnung.

micha286

#7
ZitatMeine Sicht:   Sobald eine Rechnung  über  den Restbetrag (oder auch mehr)  (den man ja akt. aus den vorangegangenen Rechnungen ermitteln kann )  ausgestellt  wird, dann handelt es sich hierbei um eine "finale" Rechnung.

Das sehe ich auch so, da sind wir absolut einer Meinung! Das Problem stellt sich bei mir nur anders da, man könnte vielleicht sagen genau umgekehrt. Genauer gesagt: durch den Haken bei blnAbschluss bestimme ich, dass der Restbetrag aus den vorangegangenen Rechnungen berechnet werden soll. Ist der Haken nicht gesetzt, so wird "ganz normal" wieder ein Abschlag berechnet, ohne die vorherigen Rechnungn in Betracht zu ziehen.

Ich habe im Anhang mal die (vereinfachte) Datenbank hochgeladen...

Weiterhin vielen Dank für euren Input!

[Anhang gelöscht durch Administrator]

Beaker s.a.

Hallo Michael,

Du gehst falsch an die Sache heran.
Abschläge und Rechnungen sind zwei ganz unterschiedliche Dinge.
Eine Rechnung ist die Erstellung einer Forderung für eine erbrachte Leistung. (Erlöse aus Lieferung und Leistung an Forderungen).
Ein Abschlag ist eine Zahlung zum Ausgleich dieser Forderung (Forderungen an Bank/Kasse).
Wobei ich einen Abschlag als Teilzahlung im Voraus betrachten würde, anders als eine Rate z.B., die ja üblicherweise nach der Rechnungsstellung bezahlt wird.
Mit Deiner DB geht das IMO nicht.
Abschläge werden nicht berechnet, sondern nur erfasst (Forderungen an Bank/Kasse), und dadurch per Saldo von der Gesamtforderung abgezogen.
Beispiel:
gezahlte Abschläge: 100,00
Rechnungsbetrag:   150,00
RestForderung:   50,00
Ein Sonderfall wäre noch, das der Rechnungsbetrag gleich den geleisteten Abschlägen ist, dann gibt es keine Restforderung wohl aber eine Rechnung, will sagen, das Konto ist ausgeglichen.
Ich habe Dir mal schnell ein Beispiel zusammengeklickt, wie ich mir das vorstellen könnte (ohne Gewähr und Anspruch auf Vollständigkeit)
Da ist auch keinerlei Funktionalität (Code) enthalten, und es fehlen natürlich auch noch jede Menge andere Tabellen, aber was weisst Du ja am besten. Bitte beachte die Feldbeschreibungen in meinen Tabellen.
Was Du da bräuchtest ist eine Prozedur, die Dir das RechnungsForm mit Übergabe der KundenNr öffnet.
Dann müsstest Du sicherstellen, dass beim Erstellen der Rechnung deren Nummer in die Tabelle Abschlaege kommt. Standardwert ist da 0, worüber auch die offenen und erledigten Abschläge gefunden werden (können).
Das geht vielleicht am besten, wenn Du das Listfeld auf dem RechnungsForm mit Mehrfachauswahl ausstattest, und dann per Code die ausgewählten bearbeitest.
hth
gruss ekkehard

P.S. Bin jetzt erstmal wieder weg, da ich dies auf der Arbeit gemacht habe (hoffentlich merkst keiner)

[Anhang gelöscht durch Administrator]
Alles, was geschieht, geschieht. - Alles, was während seines Geschehens etwas anderes geschehen lässt, lässt etwas anderes geschehen. - Alles, was sich selbst im Zuge seines Geschehens erneut geschehen lässt, geschieht erneut. - Allerdings tut es das nicht unbedingt in chronologischer Reihenfolge.
(Douglas Adams, Mostly Harmless)

micha286

Danke Ekkehard, dass du dich hier so engagierst!

Ich verstehe deine Begründungen gut, dennoch glaube ich, dass sich das Problem alleine auf die Benamung der einzelnen Posten reduzieren lässt:

Ich gebde dir Recht, dass es sich bei der Rechnung und bei einem Abschlag um verschiedene Dinge handelt. So gesehen ist in meiner Datenbank nur die Abschlussrechnung als "Rechnung" zu sehen, denn erst dann steht der tatsächliche Rechnungsbetrag fest. Da sich der Rechnungsbetrag aber über die Laufzeit verändert, lässt sich dann schlecht über "Abschläge" vom tatsächlichen Rechnungsbetrag sprechen, sondern es sind viel mehr wieder einzelne Rechnungen mit einem Rechnungsbetrag.

Mir geht es hier auch nicht um die gesonderte Abgrenzung zwischen Abschlag und Rechnung, sondern vielmehr um die Möglichkeit eine Berechnung eines Feldes (bei mir "Summe11") in Abhängigkeit von einem Steuerelement (bei mir "blnAbschluss") zu gestalten. Diese Berechnung soll im Falle von blnAbschluss=-1 dann sämtliche zuvor berechneten Felder (bei mir "Summe") mit einbeziehen.

Ist es so etwas klarer geworden?

Beste Grüße
Michael

Beaker s.a.

Hallo Michael,
Habe mir jetzt Deine DB noch mal angeschaut, vor allem das Form. Heute Nachmittag im Büro war ich so auf die Tabellen fixiert.
Da reduziert sich Dein Problem wohl auf den Steuerelementeinhalt von Text187.
Dazu als Vorbemerkung, auch wenn andere hier das anders sehen, benenne Controls nicht genauso wie das dahinter liegende Tabellenfeld. Es gibt damit zwar wohl selten Probleme, ich finde aber, dass man da besser lesen kann worauf man sich bezieht.
Also txtdatBNW statt nur datBNW (=Feldname)
Versuche mal dies:

=DomSumme([Summe];"qry_BNWGebuehren";"datBNW < #" & [Formulare]![frm_Rec]![txtdatBNW] & "#")

Testen konnte ich das nicht, da die Abfrage nicht dabei ist.
Bei Ausdrücken/Funktionen als Steuerlementeinhalt musst Du Formularbezüge immer komplett eingeben (evtl. "Forms" statt "Formulare");  - da gibt auch kein Me.

hth
gruss ekkehard
Alles, was geschieht, geschieht. - Alles, was während seines Geschehens etwas anderes geschehen lässt, lässt etwas anderes geschehen. - Alles, was sich selbst im Zuge seines Geschehens erneut geschehen lässt, geschieht erneut. - Allerdings tut es das nicht unbedingt in chronologischer Reihenfolge.
(Douglas Adams, Mostly Harmless)

micha286

Moin Ekkehard,

ich habe deinen Code gerade ausprobiert und leider eine Fehlermeldung erhalten: "#Name?". Ich habe den Code allerdings modifiziert, da das Datumsfeld im UFO steht und sich darauf beziehen sollte, oder?

=DomSumme([Summe];"qry_BNWGebuehren";"datBNW < #" & Formulare!frm_UFO_Gebuehr!txtdatBNW & "#")

Die Abfrage habe ich beim letzten Upload wohl schlicht vergessen, dieses Mal ist sie dabei. Muss evtl. noch in die Bedingung bei dem Code oben, dass ich nur die Beträge summieren möchte, für die ID_Rec übereinstimmt? Also ungefähr so:

=DomSumme([Summe];"qry_BNWGebuehren";"datBNW < #" & Formulare!frm_UFO_Gebuehr!txtdatBNW & "#" AND IDRec_F = Formulare!frm_Rec!IDRec)


Besten Dank für deine Hilfe!

[Anhang gelöscht durch Administrator]

DF6GL

Hallo ,

[Summe]      muss zwischen Gänsefüßen stehen  (und am Besten vernünftig benamst werden)
Das Datum muss evtl. in ISO- oder USA-Format formatiert werden

Formulare!xxxx    sollte als Forms!xxxx   geschrieben werden, auch wenn Access das wieder umstellen sollte.

Die Referenz auf Unterformulare, so es denn Endlosforms sind, ist fehlerträchtig.

database

Hallo,

die Datumsformatierung ist falsch!

=DomSumme("Summe";"qry_BNWGebuehren";"datBNW <" & Format([txtdatBNW];"\#jjjj-mm-tt\#"))

Den Formularbezug kannst du weglassen, da sich das Feld ja im gleichen Formular befindet wie das berechnete Feld.

micha286

Super! Das funktioniert perfekt und das Problem mit der korrekten Zuordnung zu den Rechnungen habe ich auch lösen können:

=DomSumme("Summe";"qry_BNWGebuehren";"datBNW < " & Format([txtdatBNW];"\#yyyy-mm-dd\#") & " AND [IDRec_F]=[txtIDRec_F]")

Besten Dank für Eure Mühen!!!