search

portfolio-performance / portfolio

Track and evaluate the performance of your investment portfolio across stocks, cryptocurrencies, and other assets.
http://www.portfolio-performance.info
Eclipse Public License 1.0
2.98k stars 609 forks source link

Scriptbare Importer #1184

Open lenucksi opened 5 years ago

lenucksi commented 5 years ago

Hi, danke für das prima Tool! Ich hatte versucht meine verschiedenen Depots jeweils über deren PDFs oder CSVs hier zu importieren. Leider hat das bei keinem wirklich richtig funktioniert. Hier ist sicher auch das Problem aus #727 relevant. In anderen Tickets oder Forenbeiträgen habe ich ähnliche Probleme gefunden mit irgendwann mal beigetragenen aber dann nicht mehr gewarteten Importern oder Workarounds aller Sorten. Wenn ich das richtig sehe sind Importer im Wesentlichen nur per Java baubar. Es scheint CSV-Vorlagen zu geben, aber die sind auch per Java vorgegeben.

Gab es mal Arbeit oder Ideen dahingehende irgendeine Scriptsprache einzubauen (z.B. Python via Jython, Lua oder dergleichen) um dynamisch vorhandene Importer-Features oder CSV-Funktionalitäten schnell uhnd ohne PP neu bauen zu müssen für eigene Zwecke anpassen zu können? Das könnte auch für andere einfacher anzupassen sein oder einfacher aktuell zu halten zu sein. Evtl. dann mit ohne Update für die eigentliche SW aus dem Web nachladbaren Importern?

buchen commented 5 years ago

Gab es mal Arbeit oder Ideen dahingehende irgendeine Scriptsprache einzubauen (z.B. Python via Jython, Lua oder dergleichen) um dynamisch vorhandene Importer-Features oder CSV-Funktionalitäten schnell uhnd ohne PP neu bauen zu müssen für eigene Zwecke anpassen zu können?

Echt dran gearbeitet habe ich nie.

Manche Dokumente können ganz schön komplex werden, ich weiß nicht ob man das wirklich ausserhalb einer IDE oder Tests etc. bauen möchte.

Es gibt aber auch einfachere Extraktoren wie z.B. für Trade Republic. Da kann ich mir sowas schon eher vorstellen.

Hast Du eine Idee wie das API aussehen könnte?

Als Input einfach den "Text" und als Output ein Extractor.Item? Oder ehre als Map mit den Werten und daraus baut PP dann die Buchung in Java zusammen.

lenucksi commented 5 years ago

Manche Dokumente können ganz schön komplex werden, ich weiß nicht ob man das wirklich ausserhalb einer IDE oder Tests etc. bauen möchte.

Wäre die Frage wie weit man die Infrastruktur die man für so eine API stellen würde isoliert laufen lassen könnte, dass das trotzdem testbar bleibt. Angesichts der ja eigentlich vorhandenen Modularisierung mit OSGi könnte ich mir vorstellen, dass da noch was zu holen ist.

Hast Du eine Idee wie das API aussehen könnte?

Als Input einfach den "Text" und als Output ein Extractor.Item? Oder ehre als Map mit den Werten und daraus baut PP dann die Buchung in Java zusammen.

Man könnte so ein Item nehmen, aber ich würde der Einschränkungsfreiheit halber tatsächlich eher der Map oder sogar etwas strukturiertem wie JSON zuneigen. Ich habe so einen Ansatz bei anderer Software (Go.CD) die erfolgreich viel mit Plugins macht gesehen. Die Software an sich ist in den letzten Jahren durch recht umfangreiche Änderungen gegangen und hat das immer stabil und erfolgreich überlebt. Auch hier sind die auszutauschenden Informationen relativ breit, was sich mit diesem recht flexiblen Interface eigentlich gut gemacht hat.

buchen commented 5 years ago

Man könnte so ein Item nehmen, aber ich würde der Einschränkungsfreiheit halber tatsächlich eher der Map oder sogar etwas strukturiertem wie JSON zuneigen.

JSON ist eine gute Idee. Das ist ziemlich sprachunabhängig. Was ist mit dem Input? Die Datei (PDF), oder schon den umgewandelten Text?

Im Prinzip kann man schon mit einer beliebigen Batch/Shell Script anfangen.

lenucksi commented 5 years ago

Man könnte so ein Item nehmen, aber ich würde der Einschränkungsfreiheit halber tatsächlich eher der Map oder sogar etwas strukturiertem wie JSON zuneigen.

JSON ist eine gute Idee. Das ist ziemlich sprachunabhängig. Was ist mit dem Input? Die Datei (PDF), oder schon den umgewandelten Text?

Man könnte entweder einen Pointer auf das PDF (filesystem / url) übergeben und dann eine API (siehe Go.CD mit ihrem Plugin System) die Zugriff auf den PDF-Extraktor in PP (oder ggf. was anderes) gibt anbieten oder auch beides, d.h. extrahierten Text und PDF (URL oder Daten) zusammen liefern.

Im Prinzip kann man schon mit einer beliebigen Batch/Shell Script anfangen

Exakt das. Und man könnte effektiv auch auf die Idee kommen dass man APIs ausliest / parst, z.B. also IB.

buchen commented 5 years ago

Wenn ich so darüber nachdenke, würde das bedeuten

Als Embedded Script Engine sehe ich Mozilla Rhino (JavaScript) als eine Option - das ist relativ schlank und es gibt bug fixes. Für (größtenteils) String Manipulation sollte das ausreichen. Wobei ich nicht beurteilen kann wie gut man dass in JavaScript machen will.

Nashorn (JavaScript) ist deprecated, wird nicht weiterentwickelt und aus dem JDK entfernt. Graal.js (Javascript) ist mit 16 MByte nicht so leichtgewichtig. Jython ist 35 MByte groß und es gibt auch keine neue Versionen seit 2015. Lua kenne ich nicht - es sieht so aus als bräuchte man platform-spezifische Binaries (sind aber klein) und ich habe auf Anhieb keine aktive Java Integration gefunden. Groovy und Jury kann ich nicht beurteilen, aber die Downloads sind mit 25 bzw. 30 MByte auch groß.

lenucksi commented 5 years ago

Als Embedded Script Engine sehe ich Mozilla Rhino (JavaScript) als eine Option - das ist relativ schlank und es gibt bug fixes. Für (größtenteils) String Manipulation sollte das ausreichen. Wobei ich nicht beurteilen kann wie gut man dass in JavaScript machen will.

Bei JS würde ich denken, dass einige über die üblichen Probleme die JS so erzeugt fallen dürften. Verwenden könnte man das sicher. Effektiv wäre das ja eine Variante von den JSR-223 Scripting-Sprachen.

Lua kenne ich nicht - es sieht so aus als bräuchte man platform-spezifische Binaries (sind aber klein) und ich habe auf Anhieb keine aktive Java Integration gefunden.

Hierzu fand sich https://github.com/luaj/luaj Das sieht aus als wäre es für genau den Zweck verwendbar.

Es scheint auch als könne man Clojure (JVM LISP) für derartige scripting Zwecke gebrauchen: https://dzone.com/articles/java-clojure-interop Und Kotlin ist seit Version 1.1 wohl auch JSR-223 kompatibel, so dass man das auch entsprechend integrieren könnte. (Siehe https://kotlinlang.org/docs/reference/whatsnew11.html#javaxscript-support und https://kotlinexpertise.com/run-kotlin-scripts-from-kotlin-programs/ )

Für String Manipulation und Text-Wrangling sollten Lua, Clojure und Kotlin alle mal gut sein. Aus meiner Erfahrung würde ich vermuten, dass etliche Leute begrenzt happy über Clojure sein könnten durch seinen Lisp-Hintergrund. Lua ist auf jeden Fall erprobt als Skriptingansatz und einigermaßen "anfängerfreundlich". Kotlin dürfte als neue Android-Sprache vermutlich eine relevante Popularität aufweisen und ist nach dem was ich davon gesehen habe auch freundlich für etliche Zielgruppen sowie sehr sicher sehr langfristig unterstützt.

lenucksi commented 5 years ago

Wenn ich so darüber nachdenke, würde das bedeuten

* [ ]  JSON Import-Format definieren
  (natürlich könnte man CSV nutzen, ist aber umständlich vor allem wenn man Fremdwährungen abbilden will; außerdem sollten man (optional) festlegen können, auf welche Konten/Depots importiert werden soll)

Genau. Ich würde allerdings direkt bei JSON (oder was verwandtem) bleiben, da man JSON zu CSV verbiegen kann aber nicht umgekehrt.. 

* [ ]  Import via externen Script
  (Speicherort des Scripts merken, aufrufen, Ergebnis in Wizard Page anzeigen)

Das klingt sinnvoll - das wäre quasi die sprachunabhängige Variante, die im Prinzip auch mit Bash-Skripten umgehen könnte.

* [ ]  Import via embedded Script (Engine)

Hier wäre alles noch etwas tiefer integriert - fragt sich ob das tatsächlich völlig nötig ist wenn man die komplett separierte Variante wie im letzten Punkt noch hat. Oder welche Unterschiede sich ergeben würden.

* [ ]  Definition des embedded Scripts exportieren/importieren

Meinst Du die zur Verfügung gestellte API damit?

Was sagst Du zu folgender Variante:

buchen commented 5 years ago

Hierzu fand sich https://github.com/luaj/luaj Das sieht aus als wäre es für genau den Zweck verwendbar.

Die meinte ich als nicht (so?) aktiv: Fork ohne die ursprünglichen Autoren; kein Publish nach Maven Central mehr https://github.com/luaj/luaj/issues/37; Unterstützung für aktuellere Lua Versionen 5.3 nicht gegeben https://github.com/luaj/luaj/issues/27; so 20 Issues in diesem Jahr.

Ich würde allerdings direkt bei JSON (oder was verwandtem) bleiben, da man JSON zu CSV verbiegen kann aber nicht umgekehrt..

So meinte ich das nicht. Aktuell kann man schon per CSV importieren, d.h. das Script könnte auch als Output entsprechende CSV Records erwarten. Das ist aber zu kurz gegriffen - da müsste noch was entwickelt werden. Es braucht ein JSON (oder eben ähnliches) Format.

  • [ ] Import via embedded Script (Engine)

Hier wäre alles noch etwas tiefer integriert - fragt sich ob das tatsächlich völlig nötig ist wenn man die komplett separierte Variante wie im letzten Punkt noch hat. Oder welche Unterschiede sich ergeben würden.

Guter Punkt. Was wäre der Mehrwert? Ich denke a) die Script Engine kommt mit PP direkt mit und man braucht keine separate Installation und b) man hat eine OS unabhängige Variante die es einfacher macht die Skripte zwischen den Anwendern zu verteilen. Aber es baut aufeinander auf - zunächst einmal Bash/Bat Skripte ausführen, dann eine Script Engine embedded. Wenn ich mir die Meldungen über Installationsprobleme anschaue, dann muss das ganz einfach mitkommen.

  • [ ] Definition des embedded Scripts exportieren/importieren

Meinst Du die zur Verfügung gestellte API damit?

Ich dachte an eine einfache (erste) Möglichkeit die Skripte von Nutzer zu Nutzer weiterzugeben. Vielleicht ist es auch nur ein copy & paste von dem Code selbst. Ich dachte, das Script hat vielleicht weitere Eigenschaften (Namen, Datei-typen (=PDF), ...). Aber wenn ich drüber nachdenke, dann ist das schon zu kompliziert gedacht.

PP könnte auch als CLI mit einem fertigen JSON und einer Portfolio-Datei aufgerufen werden und die passenden Inhalte in die Portfolio-Datei einbuchen sofern sie widerspruchfrei / nicht-interaktiv eingebucht werden können.

Guter Punkt. Vor ein paar Jahren hatte ich mal eine Variante da konnte man PP in der Kommandozeile aufrufen und Daten per CSV exportieren. Das musste ich wieder ausbauen weil Eclipse e4 das damals nicht unterstützte. Vielleicht geht das aber mittlerweile wieder relativ einfach.

lenucksi commented 5 years ago

Hierzu fand sich https://github.com/luaj/luaj Das sieht aus als wäre es für genau den Zweck verwendbar.

Die meinte ich als nicht (so?) aktiv: Fork ohne die ursprünglichen Autoren; kein Publish nach Maven Central mehr luaj/luaj#37; Unterstützung für aktuellere Lua Versionen 5.3 nicht gegeben luaj/luaj#27; so 20 Issues in diesem Jahr.

Danke für die Links - der Code sieht aktiv maintained aus (letzter Commit vor 4 Tagen, Antworten auf Issues), aber die anderen Probleme sind natürlich unschön. Die Möglichkeit Forks von potentiell aufgegebenen Projekten zu machen und sie wiederzubeleben ist ja einer der Vorteile von OSS. Leider entstehen dabei dann halt sowas wie blockierte Namespaces oder Namenswechsel von Zeit zu Zeit. Insgesamt gehe ich aber jetzt mit Deiner Einschätzung konform.

Ich würde allerdings direkt bei JSON (oder was verwandtem) bleiben, da man JSON zu CSV verbiegen kann aber nicht umgekehrt..

So meinte ich das nicht. Aktuell kann man schon per CSV importieren, d.h. das Script könnte auch als Output entsprechende CSV Records erwarten. Das ist aber zu kurz gegriffen - da müsste noch was entwickelt werden. Es braucht ein JSON (oder eben ähnliches) Format.

Du meinst das Parser-Skript soll PDF nehmen und CSV ausgeben? Ja, das wäre sicher auch eine Option. Was mir hier noch einfällt: Dieser Weg könnte auch ein ausgesprochen billiger Weg sein, eine wartbare Variante der CSV-Datei-Parser-Vorlagen zu erzeugen insofern als man einfach aktuelle Mappings aufschreibt, als Skript ablegt und so einfach modifizierbar und aktualisierbar hat.

  • [ ] Import via embedded Script (Engine)

Hier wäre alles noch etwas tiefer integriert - fragt sich ob das tatsächlich völlig nötig ist wenn man die komplett separierte Variante wie im letzten Punkt noch hat. Oder welche Unterschiede sich ergeben würden.

Guter Punkt. Was wäre der Mehrwert? Ich denke a) die Script Engine kommt mit PP direkt mit und man braucht keine separate Installation und b) man hat eine OS unabhängige Variante die es einfacher macht die Skripte zwischen den Anwendern zu verteilen. Aber es baut aufeinander auf - zunächst einmal Bash/Batch Skripte ausführen, dann eine Script Engine embedded. Wenn ich mir die Meldungen über Installationsprobleme anschaue, dann muss das ganz einfach mitkommen.

Ok, das klingt in der Tat sinnvoll dann.

  • [ ] Definition des embedded Scripts exportieren/importieren

Meinst Du die zur Verfügung gestellte API damit?

Ich dachte an eine einfache (erste) Möglichkeit die Skripte von Nutzer zu Nutzer weiterzugeben. Vielleicht ist es auch nur ein copy & paste von dem Code selbst. Ich dachte, das Script hat vielleicht weitere Eigenschaften (Namen, Datei-typen (=PDF), ...). Aber wenn ich drüber nachdenke, dann ist das schon zu kompliziert gedacht.

Das halte ich für einen sehr wichtigen Punkt. Das wäre effektiv ja eine Art Marketplace und Script-"Paketverwaltung". Konzeptuell vielleicht vergleichbar mit Ansätzen wie dem Zabbix-Share, Homebrew für OSX, dem Eclipse-Marketplace oder der Translator-Sammlung von Zotero. Ich habe etliche Foren-Threads gefunden (und die Probleme selbst gehabt) in denen die Probleme das Finden der passenden Metadaten zu den aktuellen Extraktoren war, d.h. welche Outputs der Banken sie erwarten (Summary-Statements, Einzelbelege), wann die letzte Wartung des Skripts war, welche Settings in den Exportern der Banken gewünscht sind (looking at you, IB), usw.

Eine Möglichkeit hier an den jeweiligen Skripten die passenden Metadaten, eine (automatische) Aktualisierung und einen (mehr oder weniger) integrierten Marktplatz/Paketverwaltung zu haben fände ich großartig. Zumal sich damit die Wartungslast evtl. auch etwas verteilen ließe bei gleichzeitiger Möglichkeit zu sinnvolle Maintainership-Strukturen zu haben.

PP könnte auch als CLI mit einem fertigen JSON und einer Portfolio-Datei aufgerufen werden und die passenden Inhalte in die Portfolio-Datei einbuchen sofern sie widerspruchfrei / nicht-interaktiv eingebucht werden können.

Guter Punkt. Vor ein paar Jahren hatte ich mal eine Variante da konnte man PP in der Kommandozeile aufrufen und Daten per CSV exportieren. Das musste ich wieder ausbauen weil Eclipse e4 das damals nicht unterstützte. Vielleicht geht das aber mittlerweile wieder relativ einfach.

Ah, cool. Das ist dann sicher einen Versuch wert. Ohne jetzt schon den tiefen Blick in den Code geworfen zu haben würde ich mich fragen ob es hier evtl. eine Möglichkeit ist die nötigen Bundles in eine andere, ggf. headless OSGi-Runtime (Equinox, Felix, ...) zu laden und das dann als CLI laufen zu lassen um solche Probleme zu umgehen?

buchen commented 5 years ago

Und Kotlin ist seit Version 1.1 wohl auch JSR-223 kompatibel, so dass man das auch entsprechend integrieren könnte.

Ich habe Kotlin als JSR-223 mal ausprobiert. Es ist nicht OSGi kompatibel (zumindest die ScriptEngine), aber ich würde es wohl passend in ein OSGi Bundle gepackt bekommen. Aber das Scripting finde ich nicht ganz einfach: Variablen aus dem BindingContext sind komisch gescopt (wobei ich die letzten Commits in Kotlin so lese, dass sich das ändert); dann finde ich Dokumentation z.B. zu kscript die ich dann mit komischen Exceptions abbrechen oder Features dokumentiert, die so natürlich nicht funktionieren (z.B. die directives). Ob ich das im Forum supporten kann?

Ich probiere mal Rhino aus. Das sollte auch über die Nashorn Deprecation hinaus gehen.

Konzeptuell vielleicht vergleichbar mit Ansätzen wie dem Zabbix-Share, Homebrew für OSX, dem Eclipse-Marketplace oder der Translator-Sammlung von Zotero.

Das ist eine super Idee. Ein PR mit einem lokal getestet Script ist viel einfacher zu erstellen. Und wenn man dann noch Testfälle hinterlegen könnte.

Insgesamt ist das eine grössere Änderung. Ich kann nicht sagen wie schnell ich dazu kommen werde.

lenucksi commented 5 years ago

Und Kotlin ist seit Version 1.1 wohl auch JSR-223 kompatibel, so dass man das auch entsprechend integrieren könnte.

Ich habe Kotlin als JSR-223 mal ausprobiert. Es ist nicht OSGi kompatibel (zumindest die ScriptEngine), aber ich würde es wohl passend in ein OSGi Bundle gepackt bekommen. Aber das Scripting finde ich nicht ganz einfach: Variablen aus dem BindingContext sind komisch gescopt (wobei ich die letzten Commits in Kotlin so lese, dass sich das ändert); dann finde ich Dokumentation z.B. zu kscript die ich dann mit komischen Exceptions abbrechen oder Features dokumentiert, die so natürlich nicht funktionieren (z.B. die directives). Ob ich das im Forum supporten kann?

Danke fürs schnelle Ausprobieren!

Ich probiere mal Rhino aus. Das sollte auch über die Nashorn Deprecation hinaus gehen.

Bin auf das Ergebnis gespannt. :+1:

Konzeptuell vielleicht vergleichbar mit Ansätzen wie dem Zabbix-Share, Homebrew für OSX, dem Eclipse-Marketplace oder der Translator-Sammlung von Zotero.

Das ist eine super Idee. Ein PR mit einem lokal getestet Script ist viel einfacher zu erstellen. Und wenn man dann noch Testfälle hinterlegen könnte.

Denke bei rein isolierten Scripts den Schritt von PDF -> gewünschte Extraktion (d.h. passendes JSON) zu testen sollte gehen, Wenn man ein Extraktions-Infrastruktur als Bundle stellt muss man die irgendwie in so einem Test-Framework laden + benutzen können. Korrekter Import in das tatsächliche Portfolio wäre dann dahinter. Um mit den potentiell persönliche Daten enthaltenden Beispiel-PDFs ordentlich umgehen zu können in einer CI müsste man sich vermutlich irgendwas ausdenken.

Insgesamt ist das eine grössere Änderung. Ich kann nicht sagen wie schnell ich dazu kommen werde.

Bin sehr gespannt! Aktuell weiß ich nicht ob ich auch Zeit dazu geben könnte, aber testen kann ich Ideen/Code gern.

ghost commented 5 years ago

In Anlehnung an #1193 i.V.m. den Pflichtfelder / Optional Feldern, aber da weiß ich nicht ob Java mitspielt.

Wäre es nicht möglich wie bspw. bei INI-Dateien bspw. SHARES=^ Summe *St\\. *(?<shares>[\\d.]+(,\\d+)?) .* aus einer Template-Datei an Java zu übergeben und per SELECT CASE den aus dem PDF ermittelten Wert an die passende Funktion zu übertragen?

Es dürfte doch möglich sein die Funktion dynamisch mit FIND, Regex MATCH und ziel-Variable zu füttern, dies in einer Schleife abzuarbeiten, auf Pflichtfelder zu prüfen dann ggf. als Transaktion bis wrap zusammen zu stellen?

Ok, bei einigen Importern wird gerechnet, dass wäre vielleicht auch noch möglich. Aber komplizierte Varianten wie Kontoauszug Onvista würden ausscheiden.

        this.addDocumentTyp(ertrag);

        Block block = new Block(
                        ".*G *u *t *s *c *h *r *i *f *t *f *ä *l *l *i *g *e *r *W *e *r *t *p *a *p *i *e *r *- *E *r *t *r *ä *g *e *");
        dividende.addBlock(block);
        ertrag.addBlock(block);
        block.set(new Transaction<AccountTransaction>()

                        .subject(() -> {
                            AccountTransaction t = new AccountTransaction();
                            t.setType(AccountTransaction.Type.DIVIDENDS);
                            return t;
                        })```

                    .section("currency", "amount", "date") //
                    .find(".*Zu Ihren Gunsten vor Steuern *") //
                    .match("^.*(?<date>\\d{2}.\\d{2}.\\d{4}) *(?<currency>\\w{3}+) *(?<amount>[\\d.]+,\\d+) *$") //
                    .assign((t, v) -> {
                        t.setCurrencyCode(asCurrencyCode(v.get("currency")));
                        t.setAmount(asAmount(v.get("amount")));
                        t.setDateTime(asDate(v.get("date")));
                    })```
buchen commented 5 years ago

Wäre es nicht möglich wie bspw. bei INI-Dateien bspw. SHARES=^ Summe St\. (?[\d.]+(,\d+)?) .* aus einer Template-Datei an Java zu übergeben und per SELECT CASE den aus dem PDF ermittelten Wert an die passende Funktion zu übertragen?

@Ragas13 Wenn ich Dich richtig verstehe, würde man die "DocumentType", "Blocks", "Section" etc. in einer Datei konfigurieren. Und die #assign würde automatisch die Werte in die Buchung übertragen. Das finde ich eine gute Idee.

Aktuell überlege ich: kann man die PDF Extraktoren nicht das selbe JSON generieren lassen. Und aus dem JSON werden die Buchungen importiert. Dann könnte man solche Transformationen wie "Kontowährung ist EUR also kann Fremdwährung von Dividenden nicht verwendet werden" an einer Stelle machen. (Aber natürlich existiert da schon viel Code - der muss auf jeden Fall mal weiterlaufen). Damit würde dann noch weniger Code in den #assign Methoden sein.

Allerdings: wer so tief in regulären Ausdrücken drin ist, kann der nicht auch programmieren? Aber gut, vielleicht nicht Java. Und PP in Eclipse aufzusetzen ist auch eine große Hürde.

lenucksi commented 5 years ago

Hier wäre zum Bauen, Testen und Aktualisieren von solchen JSON-Mappings/Extraktoren eine PP-CLI sehr nützlich. Vor allem wenn diese sich besorgen lässt ohne PP in Eclipse aufsetzen zu müssen.

damarvin commented 3 years ago

Mein Vorschlag wäre ein klar definiertes CSV (sollte zumindest die üblichen Broker-Buchungen abdecken) – oder JSON, wenn das wirklich von Vorteil wäre – in etwa so wie der aktuelle CSV-Import funktioniert, nur eben per Kommandozeile übergebbar. Dieses CSV müsste natürlich zumindest auch eine Spalte für das Gegenkonto haben, so dass das normalerweise ohne UI in das PP-Projekt (XML, ggf. gezippt / verschlüsselt) integriert wird. Nur im Fehlerfall sollte die GUI hochkommen – der übliche Dialog mit den durchgestrichenen Zeilen.

Dieses Standard-Import-CSV könnte dann von beliebigen externen oder internen Parsern / Extraktoren / Skriptsprachen erzeugt werden, der eigentliche Import wäre immer derselbe.

md1986 commented 3 years ago

@buchen Ich denke die Zeit ist reif für dieses Feature, auch wenn es erst mal einiges an Initialaufwand bedeutet. Im Moment warten alle auf die neue Version von PP damit die Importer wieder funktionieren. Hiermit könnte man dieses Problem künftig elegant umgehen und würde gleichzeitig mehr Mitarbeit aus der Community ermöglichen was wiederum die Entwickler entlastet. Vielleicht wirfst du fürs kommende Release (oder das danach) nochmal ein Auge hier drauf.

lenucksi commented 3 years ago

Was ich in diesem Zusammenhang konzeptuell auch spannend fand war der Ansatz den https://github.com/firefly-iii/firefly-iii hinsichtlich solchen "Plugins" gegangen ist (dort Importer-Plugins von FinTS über Spectre, Bunq usw. usf.) Der Autor hat sämtlichen Importer-Plugin-Code aus seiner Applikation geworfen und an der Stelle eine API bereitgestellt die andere für Importer nutzen können. Anschließend hat er die existierenden Importer noch in Stand-Alone Importer konvertiert. Im Resultat ist bereits jetzt schon eine unter PSD-2 Bedingungen funktionierende FinTS Implementation einer dritten Person dazugekommen die ganz ok funktioniert.

Speziell auch in Anbetracht der "Headless-Mode" Anfrage und dass PP wenn es läuft auch als Desktop-App so eine API aufmachen könnte und an der Stelle dann die Importer ggf. selbst steuern könnte ebenso wie im Headless-Modus einfach Import-Anfragen entgegennehmen könnte vielleicht eine Überlegung wert.

Der CD-Server GoCD von Thoughtworks nutzt für seine Plugins und größere Teile der Gesamtkonstruktion einen ähnlichen Ansatz und ist damit erfolgreich - insbesondere auch damit sich beim "Laufen die Schuhe zu besohlen" (was in dem Kontext ein Stückweiser nahezu vollständiger Rewrite ohne Unterbrechnung der Nutzbarkeit ist)

flywire commented 3 years ago

How about just describing the process for a start so users can work out ways to load data into the app.