AqBanking - AqFinance
Homebanking
Linux - Windows
HomeAqBankingAqFinanceLibchipcardDownloadsNewsMailing-Listen

AqFinance

Startseite
Screenshots
Mehr
Screenshots


29.12.2013: EBICS-Modul unter der GPL enthalten

Die aktuelle Version von AqBanking enthaelt Dank der Unterstuetzung einiger User das bisher kostenpflichtige EBICS-Modul.

AqFinance

AqFinance ist eine weitere Anwendung zur Verwaltung von Finanzen. Zugegeben, es gibt eigentlich schon genug Anwendungen in diesem Bereich, aber AqFinance weist einige Features auf, die es zumindest für mich selbst zu einem nützlichen Hilfsmittel machen.

AqFinance wird mittelfristig die Anwendung QBankManager ablösen. QBankManager basiert noch auf QT3 und ist zudem teilweise miserabel programmiert. Es war eigentlich nie als eigenständige Anwendung geplant, sondern ist stattdessen in diese Aufgabe hineingewachsen. Dadurch sind einige Teile nie wirklich durchentwickelt worden, sondern nach und nach appositionell gewachsen.

AqFinance hingegen wird bereits seit 2007 entwickelt. Eine erste Version - damals noch QT3-basiert - wurde nach einiger Zeit verworfen, als ich durch mein Studium Kontakt zum FOX-Toolkit bekam. Seitdem wurde mal mehr und mal weniger intensiv an AqFinance gearbeitet. Die meisten Features und Widgets wurden erst nach langer Überlegung und Planung implementiert.

Besonders beeinflußt hat mich dabei eine immer mal wieder auftauchende Diskussion auf den GnuCash- und KMyMoney-Listen, wo es um die Art der Verwendung von Datenbanken in diesen Anwendungen ging. Mit diesen Diskussionen im Hinterkopf begann die Entwicklung des Datenbank-Modells, die nochmals intensiviert wurde, nachdem ich beruflich kurz in Kontakt mit SQL-Datenbanken kam.

Daraus resultierend verwendet AqFinance Datenbanken etwas anders als gaengige Anwendungen. Statt beim Start der Anwendung die gesamten Daten zu lesen, öffnet AqFinance seine Datenbank lediglich und liest dabei jeweils nur die Daten, die es in seiner aktuellen Ansicht benötigt. Vor der Veränderung von Daten wird die Datenbank gelocked, so daß auch der parallele Zugriff möglich ist. Der Datenbankcode wurde in AqFinance abstrahiert, so daß nach und nach verschiedene Datenbank-Implementierungen verwendet werden können. Derzeit existiert ein Datenbank-Modul, welches seine Daten in mehreren Dateien eines Verzeichnis ablegt. Später kommen dann noch Module hinzu, die beispielsweise übers Netz verwendet werden können. Geplant ist auch ein Multi-User-Modul sowie möglicherweise auch eine Anbindung an SQL-Datenbanken (z.B. über libdbi). Die Datenbank-API ist jedenfalls auf diese Planungen hin ausgerichtet.

Teile von AqFinance wurden übrigens auch bisher schon genutzt, beispielsweise in der EBICS-Version von AqBanking-CLI. Dort vor allem zum automatischen Abgleich von Überweisungen mit Umsatzdaten.

AqFinance kann bereits Überweisungen, Umsätze und Kategorien von QBankManager importieren. Dies allerdings nicht direkt: Stattdessen kann man mit aktuellen Versionen von QBankManager seine Daten exportieren (am besten in eine CTX-Datei) und diese dann nach AqFinance importieren.

AqFinance benötigt momentan die jeweils neuesten Versionen von Gwenhywfar und AqBanking. Diese sind jedoch noch lange nicht auf allen Distributionen verfügbar. AqFinance wird allerdings in einem Paket geliefert, welches die benötigten Bibliotheken im jeweils aktuellen Stand enthält.

AqFinance ist kein Open-Source-Projekt und auch keine freie Software im Sinne der Free Software Foundation. Es wird allerdings kostenlos zur Verfügung gestellt. Ausdrücklich erlaubt ist auch die Verwaltung betrieblicher Finanzen. Ich habe AqFinance zunächst einmal für mich selbst und meinen Freundeskreis geschrieben. Möglicherweise ist es aber auch für andere ein interessantes Stück Software, daher stelle ich es auch der Allgemeinheit zur Verfügung. Für Verbesserungsvorschläge oder Anregungen bin ich dabei natürlich offen.




Speicherung der Daten

AqFinance definiert abstrakte tabellenbasierte Klassen zur Speicherung der Daten, welche in Erweiterungsmodulen implementiert werden.

Eine Datenbank besteht aus einer oder mehreren Tabellen, jede Tabelle wiederum enthält die Daten eines Typs (z.B. Umsatzdaten oder Überweisungsaufträge). Eine Tabelle enthält Objekte. Diese Objekte werden intern über Objekt-IDs identifiziert. Dabei ist es Teil des Designs, daß die Anwendung diese internen IDs nicht selber setzen kann, sondern daß diese von der Implementierung selbst (u.U. dynamisch) gewählt werden.

Eine Anwendung darf somit nicht die Objekt-Id eines Objektes einer Tabelle zu dessen Referenzierung verwenden, sondern muss dazu eigene Felder der Tabelle definieren.

Beispiel zur Verdeutlichung

Eine Tabelle könnte den folgenden Typen definieren:

Feldnummer Feldname Feldtyp Bedeutung
0 ID int Id, anhand derer ein Objekt dieser Tabelle von der Anwendung referenziert werden kann
1 IrgendEinString char Nutzdaten

Jedes Objekt dieser Tabelle enthält also ein eigenes Feld namens ID. Will man nun ein Objekt finden, welche im Feld ID den Wert 1 hält, würde ein Anfragestring so aussehen; $id=="1".

Will man aus der Anwendung heraus - oder aus einer anderen Tabelle - auf dieses Objekt referenzieren, so verwendet man den Inhalt des Feldes ID.

Wir kennen nun somit für ein Objekt 2 IDs: Einmal den Inhalt des Feldes ID sowie die momentane interne Objekt-ID der Datenbank-Implementierung. Letztere wird nur beim direkten Zugriff auf die Datenbank verwendet. Eine Anfrage mit einem Anfragestring liefert beispielsweise eine Liste von derzeitigen Objekt-IDs genau der Objekte, auf die diese Anfrage paßt.

Will man nun ein Objekt lesen oder schreiben, verwendet man die interne Objekt-Id, welche man nur durch Anfragen mit Anfragestrings erhält. Diese internen Objekt-IDs bleiben nur gültig, solange die Anwendung mit der Datenbank arbeitet. Beim nächsten Öffnen allerdings können diese internen Ids völlig andere sein! Das heißt, man darf diese internen Objekt-Ids nur in der laufenden Sitzung verwenden und muß diese Ids vor dem Zugriff durch Anfragen mit Anfragestrings ermitteln.

Das sieht auf den ersten Blick kompliziert aus, hat aber unschlagbare Vorteile: Da die internen Objekt-IDs nicht in den Tabellen und Anwendungen verwendet werden, können Datenbanken ganz einfach kopiert oder transformiert werden, weil ein kompliziertes, typenabhängiges Mapping entfällt.

Das erste verfügbare Speichermodul verwendet ein Verzeichnis zur Ablage der Daten. Jede Datei innerhalb dieses Verzeichnisses enthält eine Tabelle.

Sobald neue Implementierungen verfügbar werden, kann eine bestehende Datenbank dank des oben beschriebenen Mechanismus einfach in eine andere umkopiert werden.





Disclaimer

Auf dieser Homepage sind Links zu anderen Seiten im Internet abgelegt. Ich möchte ausdrücklich betonen, dass ich keinerlei Einfluß auf die Gestaltung und die Inhalte der gelinkten Seiten habe. Deshalb distanziere ich mich hiermit ausdrücklich von allen gelinkten Seiten auf meiner Homepage. Diese Erklärung gilt für alle auf meiner Homepage ausgebrachten Links und für alle Inhalte der Seiten, zu denen die Banner und Links führen. Eventuell genannte Marken oder Produktnamen sind Warenzeichen oder eingetragene Warenzeichen der jeweiligen Eigentümer.

Sämtliche Informationen erheben keinerlei Anspruch auf Vollständigkeit oder Richtigkeit!


Mein PGP-Schlüssel - Copyright

© 2011 M.PreußLast update: 2014/04/17