Kosten für die Entwicklung eines Features

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.

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.

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.

@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

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