Access 2013: Summe in Monatsraten aufsplitten und in Tabelle ausgeben
Hallo und guten Morgen,
ich habe eine Frage zu Access.
Ich habe eine Tabelle mit folgenden Werten
ID, Titel, Beginn, Ende, Summe, etc.
1, CoTab 1, 10.10.2016, 10.10.2019, 56.343,10€
2, CoTab 2, 10.10.2014, 10.10.2012, 46.343,10€
etc.
nun möchte ich jeweils eine Abfrage erstellen, die mit folgende Werte liefert:
1. Umsatz nach Monat
2. Umsatz nach Jahren
Kann mir jemand da einen Denkansatz verpassen? Danke!
ich habe eine Frage zu Access.
Ich habe eine Tabelle mit folgenden Werten
ID, Titel, Beginn, Ende, Summe, etc.
1, CoTab 1, 10.10.2016, 10.10.2019, 56.343,10€
2, CoTab 2, 10.10.2014, 10.10.2012, 46.343,10€
etc.
nun möchte ich jeweils eine Abfrage erstellen, die mit folgende Werte liefert:
1. Umsatz nach Monat
2. Umsatz nach Jahren
Kann mir jemand da einen Denkansatz verpassen? Danke!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 347587
Url: https://administrator.de/contentid/347587
Ausgedruckt am: 25.11.2024 um 15:11 Uhr
18 Kommentare
Neuester Kommentar
Hi
also die anzahl Monate sollte mit DATEDIFF(month,Beginn,Ende) zu bekommen sein. Aber darf ich fragen was der Rest für einen Sinn macht?
In deinem Beispiel hättest du dann 36 Zeilen mit Monat1-36 und jeweils den gleichen Wert dahinter? Ich sehe da gerade keinen Sinn? Du errechnest ja nur aus dem Gesamtbetrag den Bruchteil der Monate aus. Der Betrag ist also jeden Monat gleich.
also die anzahl Monate sollte mit DATEDIFF(month,Beginn,Ende) zu bekommen sein. Aber darf ich fragen was der Rest für einen Sinn macht?
In deinem Beispiel hättest du dann 36 Zeilen mit Monat1-36 und jeweils den gleichen Wert dahinter? Ich sehe da gerade keinen Sinn? Du errechnest ja nur aus dem Gesamtbetrag den Bruchteil der Monate aus. Der Betrag ist also jeden Monat gleich.
Moin Seastorm,
Aus den eigentlichen Daten
ID, Titel, Beginn, Ende, Summe, etc.
1, CoTab 1, 10.10.2016, 10.10.2019, 56.343,10€
2, CoTab 2, 10.10.2014, 10.10.2012, 46.343,10€
.. ergibt sich ja, wie du auch geschrieben hast, ruckzuck über DateDiff() die Anzahl in Tagen je Datensatz.
Daraus kannst du, wenn es insgesamt 1001 Tage sind und du die Gesamtkosten kennst-> prima die "Kosten pro Tag" ermitteln.
Ein Februar hat aber weniger Tage als ein Dezember, also sind doch bei 28 (29) Tagen im Monat die Kosten pro Monat kleiner als bei 30/31 Tagen.
Und wenn z.b die Laufzeit erst ab 10.10.2019 beginnt, dann sind die Kosten im Oktober natürlich auch nur die von 31 Oktobertagen abzgl. der ersten 10 Tage.
Aber - gute nachricht - evolution braucht nicht ganz viele neue Tabellen, es reicht eine neue Tabelle "Monate" mit Feld "Monat" und 12 Datensätzen, eine Tabelle "Jahre" mit Feld "Jahr" und den Jahren 2010....2030.
Den Rest können wir in der Abfrage zusammenbasteln inklusive der "Anzahl Tage des aktuellen Monats" mit einem CROSS JOIN.
Grüße
Biber
Zitat von @SeaStorm:
Du errechnest ja nur aus dem Gesamtbetrag den Bruchteil der Monate aus. Der Betrag ist also jeden Monat gleich.
Nein, ist er nicht.Du errechnest ja nur aus dem Gesamtbetrag den Bruchteil der Monate aus. Der Betrag ist also jeden Monat gleich.
Aus den eigentlichen Daten
ID, Titel, Beginn, Ende, Summe, etc.
1, CoTab 1, 10.10.2016, 10.10.2019, 56.343,10€
2, CoTab 2, 10.10.2014, 10.10.2012, 46.343,10€
.. ergibt sich ja, wie du auch geschrieben hast, ruckzuck über DateDiff() die Anzahl in Tagen je Datensatz.
Daraus kannst du, wenn es insgesamt 1001 Tage sind und du die Gesamtkosten kennst-> prima die "Kosten pro Tag" ermitteln.
Ein Februar hat aber weniger Tage als ein Dezember, also sind doch bei 28 (29) Tagen im Monat die Kosten pro Monat kleiner als bei 30/31 Tagen.
Und wenn z.b die Laufzeit erst ab 10.10.2019 beginnt, dann sind die Kosten im Oktober natürlich auch nur die von 31 Oktobertagen abzgl. der ersten 10 Tage.
Aber - gute nachricht - evolution braucht nicht ganz viele neue Tabellen, es reicht eine neue Tabelle "Monate" mit Feld "Monat" und 12 Datensätzen, eine Tabelle "Jahre" mit Feld "Jahr" und den Jahren 2010....2030.
Den Rest können wir in der Abfrage zusammenbasteln inklusive der "Anzahl Tage des aktuellen Monats" mit einem CROSS JOIN.
Grüße
Biber
OK. Jetzt habe ich verstanden was benötigt wird.
Ich hab hier kein Access installiert, kann dir also nicht sagen ob das so in Access auch umsetzbar ist, aber in SQL würde ich die Anzahl Monate zwischen Zwei Datumsangaben so auflisten:
guck mal ob das in Access machbar ist. Wenn das geht, ist der Rest ja relativ leicht zu machen . Schnitt pro Monat ausrechnen(oder gleich als Wert an den Datensatz anfügen, falls sich da nichts mehr ändert. Falls doch, funktionieren ComputedColumns in Access?), und dann die Summe der Schnitte von allen Datensätzen des Monats.
Am einfachsten wäre es wenn ihr die Daten in einen SQL Server kippt ;) Dann muss man sich nicht immer mit Access-Spezial-Müll rumärgern
Ich hab hier kein Access installiert, kann dir also nicht sagen ob das so in Access auch umsetzbar ist, aber in SQL würde ich die Anzahl Monate zwischen Zwei Datumsangaben so auflisten:
declare @start DATE = '10.10.2016'
declare @end DATE = '10.10.2019'
;with months (date)
AS
(
SELECT @start
UNION ALL
SELECT DATEADD(month,1,date)
from months
where DATEADD(month,1,date) < @end
)
select date
from months
guck mal ob das in Access machbar ist. Wenn das geht, ist der Rest ja relativ leicht zu machen . Schnitt pro Monat ausrechnen(oder gleich als Wert an den Datensatz anfügen, falls sich da nichts mehr ändert. Falls doch, funktionieren ComputedColumns in Access?), und dann die Summe der Schnitte von allen Datensätzen des Monats.
Am einfachsten wäre es wenn ihr die Daten in einen SQL Server kippt ;) Dann muss man sich nicht immer mit Access-Spezial-Müll rumärgern
Na ja,
ich sehe keinen Bedarf für mehr als reines SQL und keinen Bedarf für mehr als die paar Access-Möglichkeiten, wenn diese Hilfstabellen "Monate" und "Jahre" angelegt sind.
Natürlich wäre es einfacher, wenn CTEs (die WITH-Syntax) unterstützt werden würden, aber Hey! Das wird auch in einem Access 2055 noch nicht da sein.
Dennoch: alles, was berechnet werden muss (Laufzeit in Tagen, Kosten pro Tag, Anzahl Tage je Monat) bekommen wir mit normaler SQL-Syntax hin.
Und der TO wollte ja nur einen Denkanstoss für die Strategie.
So ein doofer CROSS JOIN von Monate x Jahre sollte nun nicht das Problem sein.
SELECT m.monat, j.jahr
FROM monate m, jahre j
ORDER BY j.jahr, m.monat
Da noch diese Cotabs-Tabelle dranflanschen mit Bedingung
...WHERE (j.jahr >year(cotabs.beginn) AND j.JAHR < year(cotabs.ende))
OR ( (j.jahr =year(cotabs.beginn) and m.monat>=MONTH(cotabs.beginn)
OR (( (j.jahr =year(cotabs.ende) and m.monat<=MONTH(cotabs.ende)
...und dann noch die paar Kennzahlen berechnen und ein GROUP BY auf j.jahr, m.monat für die Monatssummen über mehrere Projekte.
Grüße
Biber
[Edit] gerade erst den Kommentar von evolution von 14:36 entdeckt.
Dann also bei meinem Kommentar "Kosten" durch "Umsatz" ersetzen.
Nichtsdestotrotz: die Strategie mit Hilfstabellen würde ich trotzdem fahren.
[/Edit]
ich sehe keinen Bedarf für mehr als reines SQL und keinen Bedarf für mehr als die paar Access-Möglichkeiten, wenn diese Hilfstabellen "Monate" und "Jahre" angelegt sind.
Natürlich wäre es einfacher, wenn CTEs (die WITH-Syntax) unterstützt werden würden, aber Hey! Das wird auch in einem Access 2055 noch nicht da sein.
Dennoch: alles, was berechnet werden muss (Laufzeit in Tagen, Kosten pro Tag, Anzahl Tage je Monat) bekommen wir mit normaler SQL-Syntax hin.
Und der TO wollte ja nur einen Denkanstoss für die Strategie.
So ein doofer CROSS JOIN von Monate x Jahre sollte nun nicht das Problem sein.
SELECT m.monat, j.jahr
FROM monate m, jahre j
ORDER BY j.jahr, m.monat
Da noch diese Cotabs-Tabelle dranflanschen mit Bedingung
...WHERE (j.jahr >year(cotabs.beginn) AND j.JAHR < year(cotabs.ende))
OR ( (j.jahr =year(cotabs.beginn) and m.monat>=MONTH(cotabs.beginn)
OR (( (j.jahr =year(cotabs.ende) and m.monat<=MONTH(cotabs.ende)
...und dann noch die paar Kennzahlen berechnen und ein GROUP BY auf j.jahr, m.monat für die Monatssummen über mehrere Projekte.
Grüße
Biber
[Edit] gerade erst den Kommentar von evolution von 14:36 entdeckt.
Dann also bei meinem Kommentar "Kosten" durch "Umsatz" ersetzen.
Nichtsdestotrotz: die Strategie mit Hilfstabellen würde ich trotzdem fahren.
[/Edit]
Moin evolution,
hmm... das erste Statement/erste Abfrage kann ich in etwa nachvollziehen.
Da wird etwas plausibles angezeigt?
Wenn ja, dann speicher diese Abfrage unter einem Namen, den du wiederfindest (Qry_coTabDetails oder so).
So, wenn wir dann ein
SELECT * from Qry_coTabDetails
machen... was willst du da GROUP BYen , was summieren oder zählen?
Das verstehe ich nicht an der Abfrage #2...
Okay, die fehlermeldung kann ich auch nicht nachvollziehen, aber ich würde auch nie einen GROUP BY über alle Felder machen und einfach die WHERE-Klausel eins zu eins zu einer HAVIG-Klausel umwidmen.
Bestimmt steht irgendwo in der Doku, was denn alles bei HAVING nicht verwendet werden darf.
Aber einfacher wäre es vermutlich (falls Abfrage #1 funktionierenden sollte), den Details-Resultset zu nehmen und darauf rumzuaggregieren.
Grüße
Biber
hmm... das erste Statement/erste Abfrage kann ich in etwa nachvollziehen.
Da wird etwas plausibles angezeigt?
Wenn ja, dann speicher diese Abfrage unter einem Namen, den du wiederfindest (Qry_coTabDetails oder so).
So, wenn wir dann ein
SELECT * from Qry_coTabDetails
machen... was willst du da GROUP BYen , was summieren oder zählen?
Das verstehe ich nicht an der Abfrage #2...
Okay, die fehlermeldung kann ich auch nicht nachvollziehen, aber ich würde auch nie einen GROUP BY über alle Felder machen und einfach die WHERE-Klausel eins zu eins zu einer HAVIG-Klausel umwidmen.
Bestimmt steht irgendwo in der Doku, was denn alles bei HAVING nicht verwendet werden darf.
Aber einfacher wäre es vermutlich (falls Abfrage #1 funktionierenden sollte), den Details-Resultset zu nehmen und darauf rumzuaggregieren.
Grüße
Biber