Eure Meinungen/Ideen zu meinen Haushaltsbuch-Projekt

[mischaef]

@H4110
Bei Container kommt es, soweit ich weiß, aber auch auf die Leistung des NAS an. Ich habe hier zwar ein DS218+, welches mit etwas mehr Speicher sicherlich noch ausreichend sein sollte, aber das mit den Containern wäre eben wieder eine Bausstelle, mit der ich mich gar nicht auskenne. Das zusammen mit einer neuen Prog-Sprache wäre dann eine Fundgrube für Fehler und Probleme....;-)

Soweit ich weiß unterstützt die Synology auch Python, da habe ich aber keine Ahnung, wie sich das mit Website verhält oder die Oberfläche gemacht werden könnte.

Gibt es denn andere Sprachen, die für Web-Seiten genutzt werden können?Ein kleiner Virtueller Server ist ja bei meiner Synology dabei, genauso wie PHPmyAdmin (keine Ahnung, ob das heute noch Standard ist...^^).

@DJMadMax
Alles gut! ;-)

 

[H4110]

Über Container-Overhead würde ich mir keine Gedanken machen, der ist minimal. VMs sind hingegen heftig.

oder die Oberfläche gemacht werden könnte.

Genau so wie mit PHP. Entweder klassisch mit Template-Engine (alle genannten Frameworks bringen eine mit und erlauben Alternativen), oder man macht eine SPA und kommuniziert über API.

Gibt es denn andere Sprachen, die für Web-Seiten genutzt werden können?

Serverseitig jede gängige Programmiersprache.

PHPmyAdmin (keine Ahnung, ob das heute noch Standard ist...^^)

Habe ich zum letzten Mal vor etwa 20 Jahren benutzt. Ich verwende die Tools meiner IDE. Es gibt auch MySQL Workbench und pgAdmin.

 

[Tzk]

Gibt es denn andere Sprachen, die für Web-Seiten genutzt werden können?

Abseits von PHP könnte man auch in Javascript programmieren und dann z.B. node.js oder alternativ auch Golang laufen lassen. Es gibt etliche Varianten die sich im Einzelfall besser oder schlechter für deinen Zweck eignen werden...

-----

So grundsätzlich sehe ich ebenfalls die Sinnfrage ganz vorne dabei. Wenn es eine Fingerübrung für dich sein soll, dann alles gut. Andernfalls wäre die Frage, ob nicht sogar das Onlinebanking deiner Bank eine entsprechende Funktionalität hat. Sparkassen haben z.B. mittlerweile eine Art Finanzplaner, der viele Umsätze auf dem Konto direkt (automatisiert) kategorisieren kann. Da spart man sich quasi den gesamten Umweg über eine extra Software, hat aber natürlich auch begrenzte Auswertungsmöglichkeiten.

Ich hatte selbst überlegt eine Haushaltsbuch-Software zu nutzen, war bisher aber immer zu faul dafür. Da kam mir der Finanzplaner ganz recht. Der langt für meine Zwecke, weil ich meine Finanzen ganz gut im Griff habe und einfach nur sporadisch einen besseren Überblick wollte.

 

[gymfan]

@gymfan
Die Erfassung soll ganz klassisch per manueller Eingabe erfolgen. Die Eingabefelder dafür sind in meinen Augen das geringte Problem, lediglich über eine logische und praktische Aufteilung wäre noch nachzudenken.

Nur Du weisst, was Du nachher auswerten willst und ob dem alle Familienmitglieder auch zustimmen. Bei mir sind es 7 Ausgabekategorien. Dazu brauche ist, mit der von mir gewünschten Granularität, keine App zum Erfassen.

Angedacht wären dabei verschiedene Kategorien, z.b. Lebensmittel, Getränke, Haustiere, Haus, Auto, Hobby/Freizeit, Versicherungen usw

Gehst Du die ersten drei Kategorien immer getrennt kaufen? Bei mir (ohne Haustiere) landen Lebensmittel (egal, ob Grundnahrungsmittel oder anderes) und Getränke beim selben Supermarkt auf einem Kassenzettel, das zurück erstattete Pfandgeld ggf. beim nächsten Einkauf ohne Getränke auf dem nächsten Zettel (es zählte aber bisher zu 100% zu Getränken). Und kaufe ich dort auch ein paar non-Food Artikel, müsste es schon eine (für mich) sehr teure Ausgabe sein, damit ich das manuell aufteile. Die 5€ für das Druckerpapier oder der 3er-Pack LED-Leuchtmittel fallen auch bei einem 20-30€ Einkauf bei mir einfach durch und landen in den Lebensmitteln (weil der Laden das naütrlich gesamthaft abbucht).

Willst Du sowas dann auch noch nach Ausgaben für Dich und die Schule trennen, wird es (gelinde gesagt) "lustig". 2€ Papierkosten für die Schule/das Kind und 3€ für Frerizeit.

Das ganze soll bewusst nur hier zu Hause gemacht werden, wie lange wäre man im Ausland, dass man das nicht nachtragen könnte?

Keine Ahnung, was Ihr an Reisen macht. Ich wollte mir über 2 Wochen Sommerurlaub an der Nordsee nicht merken, was ich alles im Restaurant, an Fischbrötchen oder an Eintrittsgeldern ausgegeben habe. Entweder, das landet alles im "Urlaub" (dann habe ich zwei Wochen keine Lebensmittelausgaben, die ich aber real auch bei Vollpension hatte), oder ich muss das bei meinem, für solche Daten extrem löchrigen Gehirn, spätestens jeden Abend notieren.

Aber gerad ebei einer Familie wäre es sinvoll nacholziehen zu können, wo Gelder hingehen. Da sind es da mal 20 Euro für die Karte der Schulkantine, da mal Kopiergeld für die Schule usw.

Punkt 2 ist keine von Dir genannte Kategorie :-) , die Schulkantine kann man zwar unter "Lebensmittel" verbuchen (u.U. gibt es dort ja nur kostenloses Wasser zu trinken), dann ist aber eine Auswertung, wieviel teurer das Schulessen ist, nicht mehr möglich. Oder kommt das in die neue Kategorie "Schule" um es nicht auf "Kind" zu verbuchen.

Das Problem sehe ich hier ggf. in der gleichen Verwendung der Kategorien durch alle protokollierenden Personen (zählt die Schulkantine zu Schule oder zu Lebensmittel?). Das mag problemlos klappen, wenn alle das System einsehen und haben wollen. Oder es klappt nicht, weil das Kopiergeld dann doch einfach bar aus der Geldbörse dem Kind gegeben wird, man zu faul ist, das sofort einzutragen und man es Abends schon wieder vergessen hat. Dann sind die X Euro halt einfach am Ende des Monats weg, genauso, wie wenn ich das dem Verein als Spende "schenke".

Wegen der Programiersprache: Bei PHP wäre der Vorteil, dass es eben nur einem Browser bedarf, um damit zu arbeiten - auch was Datenbanken angeht.

Es bedarf, neben dem passenden Webserver, einen Browser und ist damit für mich auch nicht so schön zu debugen wie eine lokale Anwendung. Das mag aber an meinem fehlenden Wissen bzgl. PHP-Entwicklung liegen.

Keine Ahnung wie das mit .Net ist, aber ich denke da ist man an Windows gebunden, oder? Damit würden die Tablets wegfallen.

Tablets gibt es leider schonmal nicht, falls sich während der Nutzungszeit der App mal ein Apple-Mobilgerät in den Haushalt verirren sollte. Da sind mit Pech schon die von PHP generierten Webseiten an den abgebissenen Safari-Apfel anzupassen und für lokale Apps muss man sich noch mehr ausdenken (oder zahlen).

Aber wenn Du PHP nutzen willst, dann tue das. Wenn Du "früher beruflich viel programmiert" hast, weisst Du ja, dass die Sprache nur das Tool ist und Du die Sprache nimmst, die unter Deinen individuellen Bedingungen am Besten geeignet ist. Ich nutze mittlerweile fast nur noch Scriptsprachen. Nicht, weil ich die so toll finde (weder Powershell noch Python), sondern weil insb. Powershell überall dort vorhanden ist, wo meine Sachen laufen sollen und DB-Zugriff haben.

Der DB-Zugriff (auf Oracle, MSSQL und SQLite) wurde mit der Zeit von .NET nach Powershell und Python konvertiert. Alles mit identischem Funktionsumfang, um mir meine Arbeit zu erleichtern. Einzig bei PHP hatte ich das damals noch nicht gemacht, womit ich die DB-Zugriffe mittlerweile mind. zweimal komplett neu schreiben musste, weil PHP ja höchst dynamisch ist und auf Langzeit-Kompatibilität keinen Wert legt.

Bei C++ scheint das Einbinden einer DB anscheinend nicht so "trivial" zu sein

Alles abseits von C/C++ ist in den allermeisten Fällen nur ein (von jemand anderem bereitgestellter) Wrapper um die API-Aufrufe für die Datenbank. Auch die SQL-Anbindung von PHP ist dabei keine Ausnahme, nur dass es einem halt nicht sofort auffällt.

Weiter dreht sich Dein Kommentar größtensteils um den Sinn oder fehlenden Sinn eines Haushaltsbuches, um das es hier aber gar nicht geht und das die Diskussion nur unübersichtlich macht.

Klar, man kann auch das Programmieren als den Sinn hinter einem Projekt definieren. Ohne gute Datenbasis wird die Auswertung schwierig bis unmöglich. Da bei Dir mind. zwei Personen die Daten erfassen sollen, kann man sich auch darüber Gedanken machen, wie gut/identisch beide Personen dauerhaft die Daten erfassen werden. Ist das Programm kein Selbstzweck um wieder in das Programmieren rein zu kommen, muss bei allen Nutzern der Willen vorhanden sein, es auch dauerhaft zu nuzten.

Serverseitig jede gängige Programmiersprache.

Das würde ich aber auf diejenigen Einschränken, welche der genutzte Webserver auch unterstützt. Was das bei dem NAS ist (falls man dort nicht ohne großen Aufwand Container nutzen kann, weiss ich nicht. Für mich war es damals der einzige Grund, bei PHP zu landen, weil mein Provider ohne Aufpreis nichts anderes geboten hat.

Ergänzung (23. März 2024)

Sparkassen haben z.B. mittlerweile eine Art Finanzplaner, der viele Umsätze auf dem Konto direkt (automatisiert) kategorisieren kann.

Mit den von ihm genannten Kategorien geht das schlicht nicht. Auf Basis von Buchungen lässt sich nur extrem selten (=sehr hohe Einkausdisziplin) ermitteln, ob man Lebensmittel, Getränke oder anderes gekauft hat. Und Barausgabe (das Kopiergeld, aber u.U. muss das mittlerweile auch überwiesen werden) lassen sich damit überhaupt nicht tracken.

Kommt dann noch die Kreditkartenrechnung mit dreimal "Amazon" im Monat dazu, hört es mit dem Automatismus vollkommen auf.

 

[mischaef]

@gymfan
Es gibt bei "Lebensmitteln" ja immer Dinge, die man braucht und die, die eher zweitrangig sind und wo im Bedarfsfall viel gespart werden kann. Wenn ich z.B. sehe, dass die "Genussmittel" deutlich zugenommen haben, dann wäre es evt. an der Zeit, hier mal kürzer zu treten...^^

Keine Ahnung, was Ihr an Reisen macht. Ich wollte mir über 2 Wochen Sommerurlaub an der Nordsee nicht merken, was ich alles im Restaurant, an Fischbrötchen oder an Eintrittsgeldern ausgegeben habe. Entweder, das landet alles im "Urlaub" (dann habe ich zwei Wochen keine Lebensmittelausgaben, die ich aber real auch bei Vollpension hatte), oder ich muss das bei meinem, für solche Daten extrem löchrigen Gehirn, spätestens jeden Abend notieren.

Da kann man dann die Rechnungen sammeln und/oder alles in ein kleines Heftchen schreiben und später nachtragen. Und es kommt ja auch auf den Urlaub an: Bin ich in einem Hotel oder in einer Ferienwohnung?

Punkt 2 ist keine von Dir genannte Kategorie :-)

Schnell nachgetragen...^^

, die Schulkantine kann man zwar unter "Lebensmittel" verbuchen (u.U. gibt es dort ja nur kostenloses Wasser zu trinken), dann ist aber eine Auswertung, wieviel teurer das Schulessen ist, nicht mehr möglich. Oder kommt das in die neue Kategorie "Schule" um es nicht auf "Kind" zu verbuchen.

Oder Schulessen...das ist das schöne bei Datenbanken: Es sind kaum grenzen gesetzt. Da kann sich der kleine Monk in mir richtig austoben...^^

Das Problem sehe ich hier ggf. in der gleichen Verwendung der Kategorien durch alle protokollierenden Personen (zählt die Schulkantine zu Schule oder zu Lebensmittel?).

Schule (evt. auch Schulessen)...aber wozu zählen dann die Schulbrote? Man, das wird schwierig...^^

Das mag problemlos klappen, wenn alle das System einsehen und haben wollen. Oder es klappt nicht, weil das Kopiergeld dann doch einfach bar aus der Geldbörse dem Kind gegeben wird, man zu faul ist, das sofort einzutragen und man es Abends schon wieder vergessen hat. Dann sind die X Euro halt einfach am Ende des Monats weg, genauso, wie wenn ich das dem Verein als Spende "schenke".

Das liegt dann aber an der eigenen Disziplin...^^

Es bedarf, neben dem passenden Webserver, einen Browser und ist damit für mich auch nicht so schön zu debugen wie eine lokale Anwendung. Das mag aber an meinem fehlenden Wissen bzgl. PHP-Entwicklung liegen.

Für mich wäre nach der ganzen Zeit beides gleich schwierig. Nur bei PHP könnte man eben schnell etwas per Smartphone oder Tablet eintragen, damit man es eben nicht vergisst - siehe vorheriges Argument...^^

Der DB-Zugriff (auf Oracle, MSSQL und SQLite) wurde mit der Zeit von .NET nach Powershell und Python konvertiert. Alles mit identischem Funktionsumfang, um mir meine Arbeit zu erleichtern. Einzig bei PHP hatte ich das damals noch nicht gemacht, womit ich die DB-Zugriffe mittlerweile mind. zweimal komplett neu schreiben musste, weil PHP ja höchst dynamisch ist und auf Langzeit-Kompatibilität keinen Wert legt.

Die Sache bei den anderen Sprache wäre, dass ich da auch mit der Gestaltung der Eingabemasken bei 0 anfangen müsste - bei HTML/CSS bin ich da schnell wieder drinn. Auch etwas, wo weniger Fehler passieren können.

Da bei Dir mind. zwei Personen die Daten erfassen sollen, kann man sich auch darüber Gedanken machen, wie gut/identisch beide Personen dauerhaft die Daten erfassen werden.

Meine Frau leitet in einer großen Stiftung die Registratur...die wird da noch genauer sein als ich...^^

Je mehr darüber nachgedacht wird, desto mehr kommen auch Fallstricke ans Tageslicht: Kreditkartenzahlungen z.B.: Die werden zwar erst Ende des Monats abgebucht, sollten aber schon in der aktuellen Auflistung enthalten sein, damit erkennbar ist, was für den Monat noch zur Verfügung steht.

Es wird spannend...^^

 

[Tzk]

Kreditkartenzahlungen z.B.

Nicht nur das... Wenn du auf einen Schlag verschiedene Produkte bestellst, dann hast du auch nur eine Rechnung. Wurde ja (zu recht!) bei meinem Hinweis auf Tools direkt von der Bank angemerkt. Sprich am Ende hast du Posten die 1:1 durchgehen und andere, wo du eine Rechnung splitten musst. Dazu dann noch der Zeitverzug von Paypal oder der Kreditkarte und es wird definitiv spannend.

An der Stelle solltest du dich fragen wie detailliert du die Daten sofort brauchst oder ob dir ne monatliche Übersicht langt... Ansonsten kommst du mit dem Eintragen ja kaum hinterher...

 

[andy_0]

Die Diskussion über Sinn einer solchen Anwendung war hier einfach total fehl am Platz.

Meine Meinung nach ist PHP eine gute Lösung für eine solche Anwendung. Für Diagramme gibt es Komponenten wie Apex Charts - womöglich auch für PHP. Dein Ziel ist es ja nicht, eine eigene Diagramm Library zu entwickeln, entsprechend solltest du auf verfügbare Komponenten zurückgreifen.

Als Backend ist SQL natürlich eine klassische Wahl. Moderner wäre NoSQL in irgendeiner Form. Je nach deinem Datenmodell hat das Vorteile oder auch nicht. Da du schon SQL Erfahrung hast, solltest du womöglich dabei bleiben.

Dritte Normalform ist im Regelfall mehr als ausreichend. Die Anwendung sollte definitiv mindestens aus zwei Datenlayer (eine SW intern, eine fürs Datenmodell wie z.B. DB) bestehen. Das macht in der Entwickelung mehr Aufwand, aber ist später deutlich leichter zu warten.

Viel Spaß.

 

[mischaef]

So, ein paar Gedanken später:

Damit nicht alles zu einer Eingabe-Orgie verkommt und nicht jeder Posten einzeln abgearbeitet werden muss, präferiere ich aktuell eine Eingabemaske für mehrere Einträge (vielleicht 10?). Die müsste nur ein paar Felder haben: Datum, Betrag, Kategorie und ein Feld für Bemerkungen. So könnte schnell jeder Einkauf abgearbeitet werden. Vielleicht noch ein Häkchen, um meherere Einträge zu einem Einkauf zusammenzufügen - dann müsste nicht überall das Datum einzeln eingegeben werden und die Beträge könnten zur Kontrolle direkt zusammengerechnet werden (sollte über JS gehen, oder?)

Oben wurde der zeitliche Versatz angemerkt, wenn mit Karte bezahl wird. Ich denke bei der EC-Karte sollte das kein Problem sein, die Abbuchung folgt ja ein paar Tage später. Bei der Kreditkarte würde das anders aussehen. Vielleicht biete sich hier ein weiteres Feld an, damit der Einkauf entsprechend eingetragen wird. So könnte auch ein Echtzeit-Kontostand und ein virtueller ausgegeben werden, bei dem die Einkäufe schon eingerechnet sind. Stellt sich nur die Frage, wie später die Abbuchungen der KK am Ende des Monats mit einfließen.

Darüber hinaus sollte es vielleicht auch "Korrektur-Einträge" geben. Mit ganz viel Disziplin wäre es vielleicht theoretisch möglich, das Haushaltsbuch exakt auf dem Kontostand zu halten - aber im Laufe der Zeit dürfte es immer wieder Situationen geben, wo der eine oder andere Euro vergessen wird, einzutragen. Das wäre natürlich als "Fehlerquote" auch interessant, daher die Frage, ob das als eigene Kategorie geführt werden soll...

Es bleibt spannend...

 

[gymfan]

Wenn ich z.B. sehe, dass die "Genussmittel" deutlich zugenommen haben, dann wäre es evt. an der Zeit, hier mal kürzer zu treten.

Also hast Du schon die zweite neue Kategorie, die Du, im Gegensatz zu Schulbedarf im weitesten Sinne, niemals automatisiert aus einer Rechnung extrahieren kannst. Damit ist jeder Kassenbon vom Supermarkt manuell durchzugehen und im Zweifel jede einzelne Position einzeln einzutragen (Grundnahrungsmittel, Genussmittel, Getränke, "alles andere").

Schnell nachgetragen...^^

U.U. macht auch eine Funktion zum Eintragen neuer Kategorien in der Eingabemaske Sinn. Ich wollte nur darauf hinweisen, dass Du nur auswerten kannst, was auch (korrekt) eingetragen wurde. Umgekehrt gilt geenauso: ist der Report einmal erstellt und es kommt jemand auf die Idee, eine neue Kategorie einzuführen, ist mind. der Report zu ändern, mit Pech auch alle bisher eingetragenen Daten, falls die Kassenbons noch vorhanden sind.

Von daher würde ich genau das machen, was unsere Anwender in der Firma (wenn auch in einem anderen Zusammenhang) seit jeher ablehnen: erst definieren, welche Daten (hier welche Kategorien) sie auswerten möchten und erst dann mit der Datenerfassung und der Reporterstellung beginnen. Und nicht im Nachhinein versuchen, aus den Kategorien die möglicherweise richtigen Daten zu extrahieren (weil vorher jeder im Kommentarfeld einträgt, ob der Tierbedarf für den Hund oder die Goldfische war).

Die Sache bei den anderen Sprache wäre, dass ich da auch mit der Gestaltung der Eingabemasken bei 0 anfangen müsste - bei HTML/CSS bin ich da schnell wieder drinn. Auch etwas, wo weniger Fehler passieren können.

Wie so üblich ist das die eigene Vorliebe. Brauche ich keine Web-Anwendung und kann mich auf Windows beschränken, dann werfe ich Visual Studio an und habe die Oberfläche in ein paar Minuten zusammen geklickt. In HTML geht das für jemand mit Erfahrung sicher auch, meine Oberflächen, die dann auch noch (für mich) hübsch aussehen und auf allen Endgeräten nutzbar sein sollten, haben einges länger benötigt.

Je mehr darüber nachgedacht wird, desto mehr kommen auch Fallstricke ans Tageslicht:

Das sind genau die Fallstricke, die man immer wieder in Videos/Podcasts (z.B. von Finanztipp) dazu hört, wenn die Autoren über ihre Erfahrungen mit so einem detailierten Haushaltsbuch berichten. Meist wird das nur ein paar Monate durchgehalten, dann sind es die Leute leid und können die Schlüsse aus den Daten bereits ziehen.

Und nur solche Aussagen, zusammen mit meinen Gedanken, wie lange ich sowas durchhalten würde (exakt einen Supermarkteinkauf lang) führen dann zu den vermutlich negativer interpretierten Aussagen wie sie gedacht sind.

Damit nicht alles zu einer Eingabe-Orgie verkommt und nicht jeder Posten einzeln abgearbeitet werden muss, präferiere ich aktuell eine Eingabemaske für mehrere Einträge (vielleicht 10?). Die müsste nur ein paar Felder haben: Datum, Betrag, Kategorie und ein Feld für Bemerkungen.

Wie möchtstes Du die Bemerkung jemals auswerten?

Die Kategorien würde ich, wenn das platzmäßig irgendwie in der GUI geht, als touchfähige Liste und nicht als Drop-Down Menü realisieren. Bei allem abseits vom Browser auf dem Desktop scrollt sich so eine Liste einfacher wie die Auswahl aus einer Dropdown-Liste. UNd daran denken, niemals mit Mouse-Over Effekten zu arbeiten (auch nicht bei der Dastellung von Details einer Auswertung). Sowas gibt es abseits vom Desktop/Mausbedienung nicht.

Dazu könnte man nach jedem Eintrag die Auswahl in der Liste löschen (hängt aber natürlich davon ab, wie ihr die Daten erfasst, muss jede Position des Einkaufszettels erfasst werden, macht das keinen Sinn) und beim Klick auf "Speichern" prüfen, ob eine Kategorie ausgewählt wurde.

Einen Haken, um Einträge zu kombinieren finde ich eher unpraktisch. Ich würde das zuletzt eingegene Datum stehen lassen, mehr an "Kombination" wäre mir schon zu viel. Beim Öffnen der Webseite wird automatisch das aktuelle Datum eingetragen (oder keins, wenn ihr die Sachen zu >90% später nachtragt).

Ich denke bei der EC-Karte sollte das kein Problem sein, die Abbuchung folgt ja ein paar Tage später.

Dann muss sich halt ein paar Tage später wieder jemand die Zeit nehmen, das alles zu verbuchen. Mir ist es schon öfters passiert, dass ich länger überlegen musste um zu wissen, wozu eine Abbuchung gehört. Insb. freie Tankstellen sind da in der Namensgebung recht creativ. Wer beim Tanken auch noch die Tageszeitung oder die Verpflegung für die Fahrt kauft, muss das später wieder aus der richtigen der 2-3 Abbuchungen am Tag der Urlaubsfahrt heraus rechnen. Das mag wieder bei euch alles nicht zutreffen, ich tanke bei Fahrten zu meiner Mutter teils 2-3 mal an einem Tag bzw. würde das alles erst nach Rückkehr eintragen.

Bei der Kreditkarte würde das anders aussehen. Vielleicht biete sich hier ein weiteres Feld an, damit der Einkauf entsprechend eingetragen wird.

Was möchtest Du dabei mehr tracken wie den eigentlichen Einkauf? Dafür gibt es immer eine Rechnung neben der KK-Abbuchung (Döner habe ich noch keinen per KK bezahlt, selbst in NYC gab es das UBahn-Ticket, das mit der KK bezahlt wurde, als Quittung)

Stellt sich nur die Frage, wie später die Abbuchungen der KK am Ende des Monats mit einfließen.

Den Zeitpunkt Deiner Bank solltest Du kennen. Ich kann die Buchungen bei Bedarf online sofort einsehen, die Abrechnung kommt aber erst am letzten Arbeitstag des Monats.

Das nützt mir aber nichts, wenn ich nicht für die Ausgaben ein Flag "mit KK bezahlt" einfügen will. Außer "Amazon DE", "Amazon Marktet Place" und co steht da bei mir nichts, wenn z.B. Amazon darüber abrechnet. Sind dabei drei völlig unterschiedliche Kategorien in einem Einkauf, muss ich das von Hand auseinander rechnen. Ich will ja nicht "100€ Amazon" wissen (ggf. möchtest Du das, was dann aber eine zweite Kategorie für einen Eintrag wäre), wenn es 30€ Tiernahrung, 20€ Schulbedarf und 50€ Klamotten war.

Und schon könnte man auch aufzeichnen, wo man gekauft hat und wie man gezahlt hat. Also als zweites Kriterium Bar, EC, KK, PayPal,... und als drittes Amazon, Edeka, Aldi, ....

Ggf auch noch den Eintragungszeitpunkt und das genutzte Endgerät automatisch mit protokollieremn um am Ende eure Disziplin (mit oder ohne eintragende Person) darzustellen. Und wenn der nächste Punkt realisiert wird (Änderung der Einträge) auch dessen Änderungszeitstempel (ggf. ein vollständiger AuditTrail mit allen geänderten Daten) um zu ermitteln, wie oft sowas nötig war und wie der Erfassungsprozess verbessert werden kann.

Darüber hinaus sollte es vielleicht auch "Korrektur-Einträge" geben.

Wäre zwar sinnvoll, macht aber die Programmierung wieder aufwändiger. Du musst nicht nur die Eingabemaske, sondern auch eine Anzeigemaske der Einträge und eine Korrekturfunktion einbauen. Das ist aber natürlich alles kein Hexenwerk.

Mit ganz viel Disziplin wäre es vielleicht theoretisch möglich, das Haushaltsbuch exakt auf dem Kontostand zu halten

Ihr habt also 100% Kartenzahlung und kein Bargeld mehr? Taschengeld wird auch überwiesen oder nur exat der Betrag vorher abgehoben?

Ich bin altmodisch, bei mir läuft zwar das Meiste per Karte, aber Bargeld gibt es trotzdem noch. Und bin ich im Supermarkt unter einer gewissen Grenze (oder beim Bäcker oder dem Imbis), wird trotzdem bar gezahlt. Der Imbis im Urlaub letztens hatte sogar groß "nur Barzahlung" angeschrieben. Da kann man entweder wieder gehen (freut in der Eisdiele die Kinder, die sich schon auf ein Eis freuen) oder man muss auch Barausgaben verbuchen.

Bucht man nur das Abheben vom Bargeld, lässt sich dem (bei mir) keine Kategorie abseits von "Ausgaben" zuordnen.

 

[mischaef]

Frohe Ostern!

Ich wollte mal eine kurze Rückmeldung in anderer Sache geben:

Ich kann die negativen Äußerungen über PHP, die man immer wieder hört, teilweise nachvollziehen. Ich habe seinerzeit mit PHP 5.6 aufgehört und muss mich bei PHP 8.2 an vielen Stellen fast komplett neu einarbeiten - für mich ist in der Entwicklung irgendwie das Intuitive von PHP auf der Strecke geblieben. Ja, PHP ist an manchen Stellen sicherer geworden, auf der anderen Seite war es für mich früher an vielen Stellen deutlich einfacher nachzuvollziehen, was dort passiert. Das merke ich ganz besonders an den Datenbank-Sachen. Ich fand das früher deutlich zugänglicher. Jetzt sind da teilweise einfach nur kryptische Anweisungen, deren Funktion nicht so offensichtlich werden. Oder anders ausgedrückt: Ich habe jetzt eher das Gefühl, dass es nur auswendig gelernt werden muss...früher konnte es noch verstanden werden.

Kann aber auch sein, dass es nur mir so geht...^^

 

[Micha-]

Hol dir Lexware Finanzmanager und konzentriere deine Energie auf die Programmierung erweitert Auswertungen, falls du dort wirklich an Grenzen stößt.

 

[mischaef]

Es geht ja nicht nur um das Haushaltsbuch, sondern eben auch darum wieder mal was zu programieren. Und das ist wenn nur sinnvoll mit einem realen "Projekt".

 

[Aww]

Das Topic fragt nach "Meinungen/Ideen", daher – auch wenn das wie ich herauslese wahrscheinlich nicht das richtige für den TO sein wird:

Gnucash ist eine freie Buchhaltungssoftware, die auch als Haushaltsbuch taugt. Man kann eigene Kategorien anlegen, grafische Auswertungen erzeugen lassen, hat Funktionalität zum Import von Giro- / Kreditkartenumsätzen mit automatischer Kategorisierung (soweit aus Verwendungszweck zu erschließen).

Imho ist es sowohl eine gute Sache als auch ein effizienter Ansatz, vorhandene Opensource-Software zu nutzen, soweit diese im wesentlichen den eigenen Anforderungen entspricht, und ggf. um selbst gewünschte Zusatzfunktionalität zu erweitern.

 

[andy_0]

Was findest du an der DB Ansteuerung kompliziert? Vielleicht machst da was "falsch"?

Nicht das ich PHP könnte.

 

[Drexel]

Früher war Dein PHP/SQL Code wahrscheinlich auch offen wie ein Scheunentor für SQal Injections etc. Was bei einem Bastel Projekt auf Deinem Rechner noch OK sein mag, aber soätestens bei öffentlichen Webseiten ärgerlich bis kritisch wird.

Für konkrete Hilfe zu Deinen Verständnisproblemen müsstest Du allerdings mal konkreten Code posten und fragen....

Btw ich denke hier geht's nicht nur darum einfach ein Tool für seine Finanzverwaltung zu nutzen, sondern auch darum Programmiererfahrung zu sammeln, von daher ist der Hinweis auf fertige Tools nicht zielführend. Ist doch ein gutes Projekt um mit seinen Programmierskills zu wachsen...

 

[mischaef]

Ich habe kein Verständnisproblem in dem Sinne, es ist mir nur aufgefallen. Ich habe bei den neuen PHP-Sachen das Gefühl, dass vieles so kompakt wie möglich "reingequetscht" werden sollte. Ich fand das alte, mal abgesehen von den Schwächen, deutlich übersichtlicher und daher leichter zu lernen. Und gegen SQL-Is konnte man den Code ja auch damals schon absichern - hat zwar im Gegensatz zu heute die eine oder andere Zeile mehr gekostet, aber es ging.

 

[Drexel]

Ja siehst Du, um es richtig zu machen Bedarf es dann mehr Code.

Es mag sogar sein, dass es einfacher zu lernen war. Aber mit mehr Übung und Erfahrung erschließt es sich evtl doch warum das neue besser ist. Das kommt dann von allein.

Und ich denke die Basics sind in PHP immer noch einfach.

 

[h00bi]

Bei jeglichem Tool musste ich manuell so viel korrigieren, dass ich am Ende wieder bei einer einfachen Excel Liste gelandet bin.

Beispiele mit denen eine Software nicht klar kommt:
Du zahlst im Restaurant den Deckel und bekommst die Hälfte per Paypal zurück.
Du ziehst 145€ am Geldautomat, wofür sind die weg gegangen?
Du bestellt etwas und schickst teile davon wieder zurück, die Rückzahlung landet als Einkommen in der Liste, deine Ausgaben wären höher als real.
Du bekommst Geld geschenkt, musst du manuell als Bargeld und als Einkommen buchen und zusätzlich die Bargeldausgabe wieder verbuchen.

Das ständige nachkorrogieren einer teilweise nicht sofort nachvollziehbaren Softwarelogik frisst am Ende mehr Zeit als eine Exceltabelle mit mehreren Spalten.

Die Spaltenbeschreibung steht bei mir in Zeile 32, die Ausgaben werden je nach Datum in die jeweilige Zeilennummer einsortiert.

 

[simpsonsfan]

Beispiele mit denen eine Software nicht klar kommt:
[...]

Eine Buchhaltungssoftware sollte mit deinen Beispielen klar kommen. Und hier wurde ja GNU-Cash genannt.

 

[h00bi]

Nein, kommen sie eben nicht. Weil das eine Software schlicht nicht wissen kann. Sie kann Vermutungen anstellen, wenn die aber falsch sind und du erst nach 3-4 wo jemand wieder drauf schaust ist das eben noch viel schlimmer weil kaum noch sinnvoll zu rekonstruieren.

Woher soll denn eine Software wissen, dass in den 127,30€ Haben von PayPal 56,30€ für die verkaufte Fritzbox sind und der Rest die Hälfte der vorletzten Restaurantrechnung?

Oder wie soll sie erkennen, dasss die 56€ PayPal die Hälfte der letzten Restaurantrechnung sind (die evtl.noch garnicht abgebucht wurde)?
Oder wenn's mal nicht centgenau 50/50 läuft?

Oder woher soll sie wissen wo das Bargeld hingekommen ist?
Geht einfach nicht.

Kreditkartenzahlungen z.B.: Die werden zwar erst Ende des Monats abgebucht, sollten aber schon in der aktuellen Auflistung enthalten sein, damit erkennbar ist, was für den Monat noch zur Verfügung steht.

Du hast doch beim KK Herausgeber eine Einsicht in die Transaktionen, nur halt nicht als Einzelhäppchen sofort auf dem Girokonto-Auszug.


Ich mach mir einmal im Jahr auch den Spaß und Werte alle digitalen Kassenzettel von Edeka aus.
Das ist zwar nicht präzise, aber interessant isses schon.
Haufigster Einzelposten ist übrigens Milch. Aber amilch steht eben nicht immer als "Milch" auf dem Kassenzettel, da muss man dann wieder manuell gruppieren und zuordnen.

Ich bin ja mal gespannt wie Copilot sich bei der nächsten Auswertung anstellt