Moin zusammen.

Ich frage mich, wie ihr für Pecunia entwickelt. Wenn genug Spenden zusammengekommen sind, oder wenn jemand Lust hat?

Ich hätte gern das Feature, DTA, bzw. die neuen UNIFI-XML Dateien zu importieren, um die darin enthaltenen Zahlungen auszulösen. Mein Buchhaltungsprogramm wirft mir diese Dateien aus. Es gibt bereits einen Eintrag im Bugtracker von mir. Am tollsten wäre es, wenn das Ganze über eine API statt über Dateien liefe. Letzteres wäre mir aber auch recht.

Wenn ich eine Software kaufe, die das kann bin ich auch Geld los. Also investiere ich das lieber in Pecunia. Wieviel muss denn zusammenkommen, wieviele Spender brauchen wir dafür? Macht diese Frage in euren Augen überhaupt Sinn?

Danke!

Warum muss es denn unbedingt über die Pecunia GUI sein? Das basiert doch auf hbci4java und kann doch auch ohne die Pecunia Oberfläche heute schon für eigene Schnittstellen genutzt werden.

Moin onlbanker,



Ich hab das hbci4java von SourceForge geladen und gestartet. Fehler. Dann im Terminal gestartet. Fehler. Unbrauchbar für die tägliche Arbeit (ich bin Anwender, kein Programmierer) und für die ganzen Buchhalter da draußen. Eine GUI muss her. Eine GUI gibts schon. Warum nicht Pecunia erweitern?

Na ja, es gibt bereits zig Programme auf dem Markt die einen Import von SEPA Dateien beherrschen. Pecunia ist für Privatkunden, nicht für Gewerbekunden mit FiBu!
Im übrigen bieten doch die meisten Banken jetzt schon oder sonst in naher Zukunft einen direkten Upload über ihre Homepage im Browserbanking für diese Dateien.

Weil mir der Prozess nicht Mac-like einfach und komfortabel genug ist. Ich wollte halt OpenSource unterstützen statt kommerzielle Software, offenbar war das ein Denkfehler.

Das an sich ist sicher kein Denkfehler. Aber Vorrang hat hier in meinen Augen, dass man grundsätzlich die Software nutzen sollte die für die Zielgruppe konzipiert ist. Denn es ist schwer davon auszugehen, dass dies nicht die letzte Anforderung bleiben wird. Man tut sich und den Anwendern ja keinen Gefallen, wenn einem im Lauf der Zeit ständig wieder irgendeine neue Funktion fehlt. Schau dir mal die Beiträge von Sven76 an. Ich weiß nicht, wieviele verschiedene Programme der mittlerweile parallel nutzt, weil er nach wie vor kein für ihn passendes Produkt kaufen will Und zu jedem Produkt fehlt ihm am Ende doch wieder eine Funktion oder er muss Workarounds schaffen.

Und laut Pecunia Homepage richtet sich Pecunia nun mal an Privatkunden. Für Gewerbe- und Firmenkunden gibt es am OpenSource Markt - soweit ich weiß - nichts komplett fertiges, schon garnicht für Mac. Ohne ein wenig Eigenentwicklung wird das schwierig sein, beides unter einen Hut zu bringen. Aber vielleicht findet dein Wunsch ja trotzdem Gehör.

Seh ich anders. Selbst wenn ich ein Produkt kaufe, dann wird mir vermutlich auch etwas nicht gefallen. Bei OpenSource habe ich sogar viel höhere Chancen auf die Entwicklung ein wenig Einfluss zu nehmen. Und klar Magister: die Frage macht Sinn. Entwicklung bedeutet immer Zeitaufwand und besonders bei Free Opensource Projekten ist diese Rar. Daher ist Spenden immer sinnvoll. Und du kannst ja evtl in den Spendenbetreff deinen Featurewunsch schreiben.

@magisternavis, generell kann ich sagen, dass die Pecuniaentwicklung nicht im Mindesten durch Spenden getrieben wird. An sich gibt es 3 Dinge, die die Entwicklung bestimmen. Zu allererst: was selbst benötigen (da wir aber auch nur Privatpersonen sind deckt sich das häufig mit Wünschen anderer), dann natürlich was unbedingt rein muss (SEPA z.B., aber SEPA Lastschriften dagegen eher mit geringer Priorität) und dann noch was sich viele Nutzer wünschen. Mit einer guten Argumentation und Zuarbeit lassen wir uns gern überzeugen, wenn es nicht zuviel Aufwand ist. Dennoch ist eine Spende natürlich immer willkommen.

Die Entwicklung ziehlt, wie onlbanker schon schrieb, vorrangig auf Privatleute ab, schon weil gewerbliche Nutzer ganz andere Bedürfnisse haben. Diese führen nämlich oft dazu, dass Dinge eingebaut werden, die von der Masse gar nicht genutzt werden, aber das Produkt komplizierter machen. Es muss also gut überlegt sein, was rein soll und wie.

That said, wie müsste denn der Workflow aussehen? Das hat ja nichts mit Datenimport von Umsätzen zu tun, sondern, wenn ich die Frage richtig lese, mit Überweisungsaufträgen, die über eine Datei reinkommen, richtig? Wenn demso ist könnte ich mir vorstellen, diesen Import in die Überweisungssektion einzubauen. Die Daten aus der Datei werden in fertige Übweisungen in Pecunia umgewandelt und landen in der Liste der "Offenen Überweisungen" von wo aus man diese dann alle auf einmal oder selektiv abschicken kann. Klingt das nach einem brauchbaren Vorgehen? Das Verfahren über die Datei erscheint aber ganz so, als ob da eine Menge Buchungen zusammenkommen werden. Es stellt sich damit die Frage, ob solche Buchungen in der Liste für abgeschlossene Überweisungen gehalten werden sollen (wie es jetzt momentan ist) oder eher nicht.

Du hast auch noch angeregt die Übergabe dieser Daten von deinem Buchhaltungsprogramm direkt in Pecunia zu realisieren (ich nehme an, das war mit "über eine API" gemeint). Allerdings sehe ich im Moment keinen Weg, wie das aussehen könnte. Ich mache mir mal Gedanken, aber mir scheint der Weg über Dateien einfacher realisierbar zu sein.

Und dann ist da noch die Frage nach dem Format. Ich kann natürlich selbst googlen, aber wenn du einen Link zu einer guten Dokumentation hast, sehe ich mir das gern mal näher an.

Mike

Mike, wieso fragst du nach dem Format am Ende? SEPA XML und DTA ist euch doch von der Ausgabeseite schon bekannt!? Was anderes will er doch garnicht. Ihr müsstet also im Grunde einen XML- und einen DTA Parser einbauen. Ob ihr euch das antun wollt? Mit den ganzen Besonderheiten und aussagekräftigen Fehlermeldungen, wenn die FiBu oder Vereinssoft mal Mist macht..... Ich würde mir das gut überlegen!

onlbanker, ich bewege mich überhaupt nicht auf dem Level hbci4java, wo das alles abgearbeitet wird. Dementsprechend weiß ich auch nichts über das zugrundeliegende Datenformat. Ich habe das bisher rein von der GUI Seite betrachtet. Ich habe auch mal danach gesucht und eine Open Source Lib für ISO 20022 gefunden (aber in C#). Das ist schon ein höllische Brocken (weniger der Code, als all die möglichen Nachrichten). DTAUS ist dagegen ja total trivial und es wäre sicher nicht allzuviel Mühe das zu implementieren. Ob hbci4java allerdings DTA unterstützt weiß ich gar nicht.

Einen Parser für das XML (und auch DTA) ist trivial. Das Hauptproblem ist die Behandlung der verschiedenen Fälle. Welche Daten kommen da an usw. Wir würden eh nur ein Subset unterstützen.

So wie sich das für mich derzeit darstellt wird es mit UNIFI-XML nichts werden (es sei denn hbci4java kann das schon lesen). DTAUS schon eher, aber da brauche ich noch mehr Infromationen.

Mike

Achso, ist das tatsächlich so sehr gekapselt, dass man bei hbci4java garnichts von XML wissen braucht? Finde ich gut.
Bezüglich DTA würde ich sagen: Nur damit beschäftigen, wenn Langeweile herrscht. Denn das wird meiner Meinung nach mittelfristig aussterben, denn als reines Übermittlungsformat taugt es nichts (schonmal garnicht für SEPA Nachrichten), da gibt es weitaus bessere. Und wenn man es bei keiner Bank mehr los wird taugt es auch dafür bald nicht mehr.

Ganz objektiv finde ich den Ansatz von Subsembly ganz gut: http://subsembly.com/de/supa.html
Wenn sich das mal ein bisschen etablieren würde könnte das ein würdiger Nachfolger und Ersatz für DTAUS werden. Es ist einfach, frei verfügbar und taugt auch für die vielen SEPA Felder. Die Kunden müssten halt mehr auf ihre Vereinsverwaltungs- und FiBu Softwarehäuser einwirken. Mal schauen, was sich da noch alles so tut. Die Banken scheinen mit Upload Möglichkeiten für XML im Webbanking etwas hinterher zu hinken, also werden einige noch Probleme bekommen.