Feature Request: Umsätze nach Kategorie, 2 Spalten Durchschnitt 1 Monat/12 Monate

Hallo,

ein simpler Change, eine große Wirkung.

Die Funktion Auswertungen->Umsätze nach Kategorien nutze ich immer seltener, weil sie nicht viel mehr liefert als die "Umsätze"-Ansicht in Tree-Form. Ich würde die Kategorien vor allem deswegen brauchen, um durchschnittliche Ausgaben zu errechnen.

Konkret wären 2 weitere Spalten sehr sinnvoll für das Thema Auswertung:

• Pro Jahr: Normalisierte Umsatzsumme pro Jahr
  Im Bereich der Renditen hat diese Größe eine Bezeichnung, "Interner Zinsfuß" IZF. Hier möchte man auch bei beliebigen Investitionszeiträumen eine normalisierte Größe in Form einer %Rendite p.A. Per Gesetz ist bei Verträgen bereits der "Effektivzins" Pflicht geworden.
  
• Pro Monat: Normalisierte Umsatzsumme pro Monat
  Bei Umsätzen interessiert zusätzlich meist der Monatszeitraum, da auch Gehälter monatlich fließen und man seine FIxkosten und weitere Ausgaben ebenfalls auf den Monat runterbrechen möchte.
  

Beides wäre simpel zu realisieren, indem man die Summe durch den gewählten Zeitraum teilt und mit 1 Monat oder 12 Monaten multipliziert. Die beiden Spalten wären wirklich hilfreich für eine Auswertung.
Ziel für den Benutzer ist es natürlich, repräsentative Zeiträume zu wählen, also entweder genau ein Jahr, wo wiederkehrende jährliche Zahlungen enthalten sein sollten, oder über mehrere ganze Jahre. Bei ersterem wäre die 12-Monats-Spalte natürlich identisch zur Summe. Manche Ausgaben wie eine Küche oder ein KfZ möchte man aber evtl. auf 5 oder 10 Jahre mitteln, sonst verfälscht das die Jahresausgabe sehr.

Ich hatte vor langer Zeit mal hier Perl-Scripte vorgestellt, die eine solche Berechnung aus den Exports generieren und in eine CSV-Exportieren, die man dann mit Libreoffice weiterbearbeiten kann. Den Thread finde ich seit der Umstellung des Forums nicht mehr. Jedenfalls sehr ausfwändig und fehleranfällig. Die beiden Spalten würden das komplett ersetzen.
Außerdem müssten sich diese beiden Spalten sowie die Baumansicht natürlich auch effektiv in die üblichen Formate wie PDF exportieren lassen. Derzeit lässt sich zwar die Liste Kategorie-gruppiert exportieren, eine Ansicht des Trees ist das leider noch nicht.

Ich kann deinen Beitrag nicht genau einordnen. Du meinst, diese Anforderung sei zu speziell und passt nicht in Hibiscus bzw. zum bisherigen Konzept? Beschreibe das bitte nochmal.
Ich nutze Hibiscus privat, ich weiß nicht, was das damit zu tun hat. Machst du keine Haushaltsbuchführung, was du monatlich für Energie, Lebensmittel und Hobbies ausgibst? Beim Hausbau in Eigenarbeit kommt da halt ein bisschen mehr zusammen.

Also der Wunsch klingt schon ziemlich speziell. Mir hat bisher auch noch kein anderer User einen ähnlichen Wunsch geäussert. Hinzu kommt, dass bereits jetzt in "Umsätze nach Kategorie" eine ganze Menge Rechnerei stattfindet (Aufbau des Baumes mit dynamischer Zuordnung der Umsätze anhand der Suchbegriffe und Berechnung der Summen pro Kategorie). Dort jetzt noch zusätzlich Werte zu berechnen, würde den Rechenaufwand - und damit die nötige Zeit zur Anzeige - weiter erhöhen. Für eine Funktion, bei der ein Grossteil der User womöglich gar nicht weiss, wofür genau die Zahlen eigentlich gut sein sollen.

Ich bin jedenfalls skeptisch bei diesem Feature, mir erscheint es sehr speziell.

Ich weiß ja nicht, wie ihr euer Haushaltsbuch führt, aber wenn ich meine Ausgaben und Konsumkosten in Verhältnis zu meinem Gehalt rechnen möchte, dann benötige ich monatliche Einnahmen/Ausgaben. Manche Gebühren werden jährlich, halbjährlich oder Viertel-jährlich bezahlt. Mir kommt nur immer wieder die Vermutung, dass ihr das alle nicht macht, bzw. Hibiscus gar nicht intensiv einsetzt. Klar kann man hier und da mal eine Überweisung machen. Aber wenn ich schon alle Buchungen dort habe, möchte ich gerne auch Berechnungen anstellen.

In meinen Augen passt eine normierte Monats-Summe und Jahres-Summe sehr gut in die "Umsätze nach Kategorie" Tabelle und würde weit weniger ins Gewicht fallen als die Pattern-Filter für Kategorien.
Das schöne an der "Umsätze nach Kategorien" Ansicht ist, und das ist leider derzeit die einzige Funktion, dass sie Umsätze rekursiv summiert. Das heisst, ich habe am Ende Oberkategorien wie Lebensmittel, Energiekosten, KfZ, Haus, Möbel,... in der untersten Ebene pflege ich meist Kategorien, für die sich Patterns erstellen lassen, wie "Baustoffhandel XY", der natürlich in der Oberkategorie "Haus/Baustoffe/" hängt.
Wenn man nun auf jeder dieser Tree-Ebenen die Berechnung "pro Monat" und "pro Jahr" hat, dann ist das ein guter Überblick, was "Lebensmittel" pro Monat kosten, auch wenn darunter zig Lebensmittelhändler hängen. Meist interessieren mich für den Überblick nur diese Oberkategorien wie Lebensmittel, Kfz, Haus,.... d.h. im Moment nehme ich meist Zeiträume von 1 Jahr und teile jeden Betrag durch 12. Das mache ich händisch mit dem Taschenrechner, das kann also nicht soviel Performance kosten. Wenn es programmatisch gemacht wird, hätte man den schönen Vorteil, auch mal 3 Jahre als Referenz zu nehmen und auf den Monat zu mitteln.

Zum Thema Performance. Olaf, du sagst, dass bereits die dynamischen Kategorie-Patterns sehr teuer sind. Ich glaube gerne, dass die Glob und Regex-Filter für jeden einzelnen Umsatz Performance kosten, das steht aber doch in keinem Vergleich zu einer 3-Satz Rechenoperation von kleinen float Zahlen.

Weiterhin nutze ich die Patterns gerne für neue Umsätze. Ich habe damals aber bereits die Funktion vorgeschlagen, dass mit der Aktion "Geprüft" auch die Kategorie festgesetzt wird. Das sichert mir z.B., dass bei Patternänderungen viele alte Einträge plötzlich umsortiert werden. Bei jährlichem Anbieterwechsel z.B. aktualisiere ich dort regelmäßig die Kundennummer, um nicht mit der Zeit immens lange, teure und anfällige Patterns zu brauchen. Die Resourcen beim Anzeigen der "Umsätze nach Kategorien" hält sich bei mir also in Grenzen. Weiterhin besteht diese Filteroperation für Kategorien ja auch für die "Umsätze" Ansicht. Diese dauert bei mir sehr lange, wenn ich sehr lange Zeiträume auswähle. Ich versuche daher hier immer sinnvolle Zeitfilter wie "Dieses Jahr" zu wählen.

Der Gedanke zum IZF kam mir bei der Java-Applikation "Portfolio Performance", die in einem ganz ähnlichen Umfeld wie Hibiscus entstand und Rendite-Übersicht über Depots ermöglicht, nicht das Kaufen/Verkaufen an sich, ebenfalls ein 1-Mann Projekt mit einer User-Gemeinde ist.

Im Grunde benötige ich diese Funktion für die regelmäßigen Ausgaben, während ich die lange ersehnten Tags benötige, um Projektweise die Gesamtkosten zu ermitteln (#Urlaub_2014_Brasilien, #Projekt_2018_Terrassenbau, #Projekt_2016_Heizungsanlage etc.)

Beide Funktionen gliedern sich gut in Hibiscus ein, auch wenn es nicht jeder benötigt. Es ermöglicht aber sehr leistungsstarke Übersichten.

Da meine Datenbank mit der Zeit recht groß wird und die Synchronisation per Datei-Sync schwerfälliger wird, erwäge ich sowieso den Umstieg auf eine externe Datenbank. Dann könnte ich solche Berechnungen evtl. in SQL erledigen. Trotzdem sollte die Applikation Hibiscus natürlich flexibel und umfangreich bleiben.

Ok, lass uns das mal visualisieren, von mir aus mit meinen reellen Zahlen. Von den Unterkategorien nenne ich nur einige exemplarisch. Die Tabelle baue ich mal so auf, wie sie derzeit in Hibiscus ist.

T_gesamt = 24m (01.01.2017 - 31.12.2018)


Das ist die aktuelle Ansicht. Die Hauptarbeit ist hier bereits gemacht, die
Summen über alle Einzel-Beträge sind ermittelt. Die Gesamt-Summen sind aber
für die Haushaltsführung weniger interessant.

Die Tabelle würde nun mit den neuen Spalten so aussehen:

Erst in diesen Spalten sieht man aussagekräftige Daten. Wenn die Bedeutung der Spalten zu komplex ist, was ich nicht einsehe, kann man sich oft mit Online-Tooltips helfen, um neuen Nutzern den Einstieg zu erleichtern.

Diese Berechnung dürfte nicht viel kosten, selbst wenn Sie bis auf die Einzelposten runter errechnet wird.
Die Formel ist ØMon = Betrag/T_gesamt bzw. darauf aufbauend ØJahr = ØMon x 12.
Die Berechnung könnte man evtl. auch verlagern, bis die Zweige ausgeklappt werden, was man oft gar nicht tut.
Ansonsten würde keine aufwändigere Tabellenkalkulation oder Broker-Software auf heutigen Rechnern funktionieren, da gibt es weitaus teurere Algorithmen.

Natürlich kann man das weiterspinnen, für die Lebensmittel wäre die Tagesration wieder interessant oder es könnte ein individueller Durchschnittszeitraum konfiguriert werden, aber mit den 1Mon. und 1Jahr Spalten hat man schon die wichtigsten Werte. Ich möchte es ja nicht übertreiben.
Und wen das alles gar nicht interessiert und wer nur 2 Überweisungen pro Monat mit Hibiscus machen möchte, der schaut eh nicht in diese Ansicht rein.

Portfolio Performance z.B. liefert konfigurierbare Ansichten, wie viele Online-Broker auch. Da kann sich jeder die Spalten aktivieren, die er sehen möchte. Und da gibt es neben IFZ diverse andere Indikatoren und Durchschnittsberechnungen. Parallel ruft die Software für bestehende Posten die Tageskurse online ab, ich sehe da schon Analogien zu Hibiscus, wenn auch für einen anderen Usecase.

Jedenfalls mache ich diese Berechnung derzeit von Hand. Mein alter Ansatz von 2013 war ein Perl script, den Output davon habe ich als CSV wieder mit Libreoffice weiterverarbeitet. Das war sehr aufwändig. Alternativ könnte man den CSV-Export von Hibiscus auch direkt mit Libreoffice referenzieren und dort die Berechnungen machen. In allen Fällen ist die Berechnung an sich für den Rechner ein Klacks, die Bedienung der Scripts und Import/Exports aber sehr aufwändig.

Offtopic: Analog dazu führe ich z.B. für unseren Energieverbrauch, d.h. Strom, Gas, Wasser auch, eine Tabellenkalkulation, wo ich auch verschiedene Durchschnitte berechne:
Monatsverbrauch/kWh
durschnittlicher Monatsverbrauch der letzten 12 Monate/kWh
Summe/kWh 12 Mon.

Und damit nun nicht jeder denkt, das sei nur aus Liebe zu den Zahlen... Bei jedem Anbieterwechsel schaue ich kurz nach, welcher Verbrauch anvisiert ist. Und für den anstehenden Wechsel der Heizungsanlage kann ich damit den reellen Energiebedarf errechnen nach Modernisierungsmaßnahmen.

Nein, wird sie eben nicht. Ich verwende die Auswertung "Umsätze nach Kategorie" selbst auch. Allerdings für den Zeitraum eines Monats (unabhängig ob aktueller oder letzter Monat). Ich wähle dort NIE ein ganzes jahr als Zeitraum. Ergo werden auch nur die Umsätze eines Monats geladen. Und nicht die von einem Jahr.

Ich kann nicht durchschnittliche Monats- oder Jahreswerte errechnen, wenn ich davon ausgehen muss, dass der derzeit angezeigte Zeitraum gar nicht repräsentativ ist. Die Extrapolation einer Woche auf ein ganzes Jahre ergibt dann blosse Fantasie-Zahlen.

Und wenn ich doch mal sehen will, wie sich die Umsätze einer Kategorie im Laufe der Zeit entwickeln, dann klicke ich auf den Reiter "Im Verlauf". Dort sehe ich die Entwicklung über den Zeitraum.



Das kann man beim User aber nicht voraussetzen. Die Zahlen der beiden Spalten würden nur dann sinnvolle Werte liefern, wenn ich einen Zeitraum von mindestens einem Jahr auswähle. Das mache ich z.Bsp. wie gesagt NIE.

Außerdem wollte ich noch anmerken, dass wir hier über ein Feature sprechen, das extrem einfach zu implementieren ist. Korrigiere mich bitte, wenn das falsch ist. Die Sache mit der Performance wäre einfach ein Versuch wert, mein Rechner von 2012 würde das schaffen . Dies ließe sich auf jeden Fall lösen, indem einfach alle Spalten der Tabellen auswählbar sind, d.h. Kontextmenü auf dem Tabellenheader, dann per Checkbox Columns ein- und ausschalten. Manche mit kleinen Monitoren benötigen evtl. Dinge wie Kategorie oder GK BIC gar nicht. Das konfigurierbar zu machen, wäre natürlich wieder etwas mehr Aufwand.

Versteh mich nicht falsch, ich schätze die Arbeit hinter Hibiscus sehr. Software ist nur selten fertig und lebt vom Change-Management. Und bei anderen Projekten ist das oft zielführend, wenn sich eine Software durch Change-Requests langsam weiterentwickelt, ein bisschen wie offenes Produkt-Management in der Opensource.
Finanziell, ja, das wäre mir natürlich auch etwas wert. Wenn ich der einzige Befürworter wäre, würdest du davon aber auch nicht reich. Zumindest hätte ich dir nie die gesamte bisherige Entwicklung an Hibiscus bezahlen können, und mit den bisherigen "Zuschüssen" ist das mit Sicherheit auch nicht ansatzweise entgolten. Eine Alternative ist Crowdfunding, finde ich aber auch nicht ideal, wenn immer das Feature gewinnt, was den größten Betrag erhalten hat... Aus Entwicklersicht ist es für ein Produkt auch nicht immer zielführend alle Kundenwünsche einzubauen. Daher möchte ich hier konstruktiv neue Features besprechen und den Usecase mal zusammen durchdenken.

Überzeugungsarbeit. Gut, ich geb's auf.

Es macht auch bei dem Zeitraum 1 Jahr bereits Sinn, zumindest für eine Spalte, die andere ist dennoch gültig. Auch ungerade Zeiträume machen Sinn, wenn z.B. eine Buchung in den Januar gefallen ist, dann legt man den Zeitraum halt bis zum 03. Januar.
Es wird in jedem Fall der Zeitraum genommen und auf die wichtigen Referenzzeiträume 1 Monat und 1 Jahr normalisiert.

Ich habe mir gerade zum ersten Mal den Kategorien->Verlauf angeschaut. Ehrlich gesagt sehe ich da nichts, das ist auch der Grund, warum ich den ich vielen Jahren noch nie genutzt habe. ich sehe dort erstmalig meine Kategorien numeriert, es sind 148 Kategorien. Dies wird wahrscheinlich zur nächsten Verwunderung führen. Da ich aber viele Einzelgeschäfte anhand der Patterns zuweise, sammelt sich da halt etwas an über die Zeit. Links sehe ich nur viele Blöcke in Farben, die ich kaum unterscheiden kann, weil sie einfach zu ... sind. Farbenblind bin ich nicht, ich kann euch auch gerne einen Screenshot zeigen und damit endgültig offenlegen, in welchen Geschäften wir einkaufen

Ich prüfe die eingehenden Zahlungen in Hibiscus und füge die, die nicht über Muster erkannt werden, Kategorien zu.
Diese Auswertung mache ich nicht jeden Tag, in den vielen Jahren seit meinem Script auch erstmalig wieder, daher der Feature-Request. Wo ist da der Aufwand? Ich weiß, es gibt Leute, die wissen nicht, was auf ihren Konten passiert.