Das Datenmodell von Portfolio Report wurde vor Kurzem um Klassifikationen erweitern. Was noch fehlt ist die automatische Integration/Download in PP.
Liesse sich das mittlerweile schon soweit nach aussen geben, dass die GUI - oder meinetwegen erstmal halbversteckt als command line arg o.ae. - eine Importmoeglichkeiten anbietet? Experimentell, unfertig, ganz fixe vereinfachte Anforderungen an das Format, einfache Fileschnittstelle zu CSV/XML, was immer erstmal das Einfachste ist.
Das waere aus meiner Sicht schon hilfreich und Leute wie ich, die programmieren koennen aber vielleicht nicht in das Javageraffel reinfassen wollen koennten die ersten Konvertierungen die o.g. Schema bedienen schon einmal konkret mit ihren Mitteln (bei mir waere es wohl Python) anfassen. Ich habe gerade meinen Vanguard All-World und einen anderen ETF haendisch integriert und eigentlich bringt der erste alles als Excelfile mit, der Zweite auch irgendwie, aber natuerlich anders. Trotzdem muss ich halt immer noch die Zahlen muehsam im Klassifizierungstool eintippen, das ist der einzige Showstopper. Das Excel in Beliebiges zu massieren, waere aber kein Problem - nur das Schema fuer das Interface zum Datenmodell und ein Import fehlen.
Im weiteren Ausbau wuerde ich wahrscheinlich die Standardklassifizierungen (MSCI Regionen, Branchen GICS etc.) sukzessive mit darauf spezialisierten Schemata ausbauen, gegen die jeder seine Importereingaenge schreiben kann. Da entsteht dann schon etwas und die Eintrittsschwelle wird gesenkt. Weitergehende Automatisierung kann man immer noch spaeter machen. Der Endpunkt waere komplett dynamisch fuer beliebige eigene Klassifikationen, die deklarativ an ein Datenmodell andocken.
Sorry, aber ich kann Deinen GedankengÀngen nicht ganz folgen.
Portfolio Report ist eine zentrale Datenbank. Sie speichert neben Wertpapierstammdaten, Kursen eben auch Klassifikationen. Es ergeben sich hier zwei Schnittstellen:
Export zu Portfolio Performance zum Abrufen der Daten
Import von beliebigen/verschiedenen Quellen, um die Datenbank zu befĂŒllen
Deine Idee ist jetzt (wenn ich es richtig verstehe, bitte korrigiere mich), einen Export nach CSV zu bauen, den man z.B. mit einem Python-Skript einlesen und in die XML-Datei von Portfolio Performance einfĂŒgen könnte. Quasi als Ersatz dafĂŒr, die Schnittstelle in Portfolio Performance einzubauen. Habe ich das richtig verstanden? Falls ja, dann sehe ich den Sinn darin nicht. Das wĂ€re ein Workaround, der nur fĂŒr einen Bruchteil der Nutzer zugĂ€nglich ist, diverse Risiken in sich trĂ€gt und nicht wirklich einfacher ist, als es direkt in Portfolio Performance zu integrieren.
Ich will einfach extern erstellte Klassifikationsdaten mit dem genannten Datenmodell von PP abgleichen / in es importieren koennen. Dazu brauche ich ein Interface, wie saehe das aus? Wie docke ich da als Programmier an, ohne mich mit PP-Interna befassen zu muessen? Also ganz konkret:
Fuer die Vanguard Fonds kann ich mehrere Excel sheets downloaden, die die Bestandteile aufschluesseln. Beim All-World mindestens nach Regionen und nach ICB (Branchen wie sie FTSE definiert). Um die in PP zu bekommen, brauche ich ein Interface. Ich will einfach nur wissen, wie oder ob das von aussen angesprochen werden kann.
Ich selbst wuerde fuer den Anfang meine Excelsheets hernehmen und so transformieren, dass PP das versteht. Diese Info muss ich dann aber irgendwie aus PP einlesen koennen. Wie macht man das? Mein Teil waere die Aufbereitung. Z.B. wuerde ich fuer den Moment die ICB-Daten fuer den Vanguard in GICS-Daten wandeln, weil PP (noch) keine vorgefertigte ICB-Klassifizierung kennt.
Auf Dauer und am Schoensten waere es natuerlich, wenn man das erweitern koennte, also jede Art von Klassifikationsschema extern erstellen und dauerhaft in PP importieren koennte. Und danach dann die Daten des konkreten Wertpapiers/Fonds, die in verschiedenster Form vorliegen koennen und durch spezialisierte Importer fuer PP und seine Klassifikationen verstaendlich aufzubereiten waeren. Wenn eine oeffentliche Schnittstelle definiert waere, kann das komplett aus der eigentlichen Programmentwicklung ausgelagert werden.
Zusammengefasst waeren das folgende Komponenten:
Schema, welches eine Klassifikation definiert
Daten die durch Importer so vorbereitet werden, dass sie durch diese Schemata/Klassifizierungen beim Einlesen evaluiert werden koennen
Weiterverarbeitung in PP selbst durch sein internes Datenmodell.
Ich hoffe ich bringe jetzt nicht noch mehr Verwirrung rein, aber meint ihr mit âKlassifikationâ beide das gleiche? Es geht doch hier @traits um die Info, die in PP âTaxonomieâ genannt wird. Und die liefert Portfolio Report doch nicht, oder?
Okay, danke fĂŒr die Klarstellung. Dann habe ich nur noch eine Frage und bin dann wieder weg: wo finde ich Infos ĂŒber die Schnittstelle mit der ich bei Portfolio Report die âKlassifikationâ abholen kann.
Ach gerade im JSON gefunden:
Stand der Dinge ist, dass âPortfolio Reportâ Klassifikationen zentral in der Datenbank speichert und sie per JSON-Web-API bereit stellt. Aktuell scheint das nur ein Klassifikationsbaum zu sein (âCountryâ) aber theoretisch können dort viele Klassifikation gepflegt werden.
Eine automatische Ăbernahme der Daten in âPortfolio Performanceâ ist angedacht (aber noch nicht in Arbeit?).
Falls Portfolio Performance Klassifikations-Daten von Portfolio Report importieren könnte, kann man (@traits ) sich eventuell auch in den Import einklinken und auf dem selben Weg eigene Klassifikationsdaten (die es vielleicht in P-Report noch nicht gibt) importieren.
Was ich jetzt an der Situation etwas unschön finde, ist dass Portfolio Report mit seinen taxonomyUuid nicht so recht kompatibel ist mit den vorhandenen Klassifikationen (z.B. Regionen MSCI oder Industrie GICS), die von vielen User schon genutzt werden. Die vorhandenen Klassifikationen haben (soweit ich das sehe) zufĂ€llige UUIDs und Portfolio Report wird fĂŒr diese nie die passende Info liefern können. Portfolio Report wird immer eigene Klassifikations-BĂ€ume (mit eigenen nicht zufĂ€lligen UUIDs) mitbringen mĂŒssen, die neben den schon vorhandenen Klassifikationen importiert werden mĂŒssen.
Falls ich wieder meilenweit neben der Spur sein sollte, wĂŒrde ich mich ĂŒber einen nachsichtigen Wink freuen.
Ah, ich sehe gerade einen eigenen Irrtum, vielleicht ging das gegenseitige Verstehen deshalb leicht suedwaerts:
Es ging urspruenglich um Klassifikationen fuer Portfolio Report. Mmh, ich persoenlich wuerde das gern in PP selbst haben wollen. Die Onlinegeschichte sehe ich nur als einen speziellen moeglichen client, der auch darueber kommunizieren koennte. Ich wuerde mich ungern fest an einen solchen Dienst binden.
Naja, irgendwas muss Portfolio Report als SchlĂŒssel benutzen
Die UUIDs von PR können â das hast Du korrekt beschrieben â nicht identisch sein mit den UUIDs, die PP ggf. schon vergeben hat. Daher werden z.B. bei Wertpapieren zwei UUIDs in PP gespeichert. Die fĂŒr PP eindeutige und die fĂŒr PR eindeutige. (Plus die Möglichkeiten dieser VerknĂŒpfung herzustellen bzw. zu lösen.)
Bei den Klassifikationen gibt es in PR darĂŒber hinaus an jedem Knoten einen Code (der innerhalb des Baums eindeutig ist). Bei den LĂ€ndern ist das der zweistellige ISO-LĂ€ndercode. Ist schon eine ganze Weile her, dass ich mit @AndreasB darĂŒber gesprochen hatte, aber ich meine damit sollte ein Mapping möglich sein.
GrundsÀtzlich sehe ich zwei Möglichkeiten, wie man die Klassifikationen von PR nach PP bekommen kann:
Klassifikationen von PR werden mit den Klassifikationen, die in PP gepflegt werden können gemischt. Dann muss man mappen (siehe oben) und mit allen SpezialfĂ€llen, die dabei auftreten können, umgehen (Löschen, Umbenennen, Verschieben, WidersprĂŒche, âŠ). DafĂŒr ist der Nutzer flexibel und kann fĂŒr bestimmte Wertpapiere eigene/abweichende Klassifikationen pflegen, fĂŒr andere die von PR nutzen. Evtl. ist genau das aber auch verwirrend und fĂŒhrt zu Fehlern (Ă€hnlich wie die Anlage eigener Wechselkurse).
Klassifikationen von PR verhalten sich in PP anders als die ĂŒbrigen Klassifikationen und können in PP nicht geĂ€ndert werden. Dann spart man sich die Behandlung vieler FĂ€lle und sorgt fĂŒr einheitliches Verhalten dieser Klassifikationen bei allen Nutzern. Ănderungen dieser Klassifikationen können nur zentral erfolgen. Das wĂ€re momentan meine favorisierte Lösung und erstmal ein Anfang, den man ggf. weiter ausbauen kann.
Wenn Du Interesse hast, daran zu bauen, lass uns gerne mal dazu sprechen/telefonieren.
Nein, von Portfolio Report fĂŒr Portfolio Performance.
Ich bin noch nicht so 100% ĂŒberzeugt. Eigentlich habe ich einen anderen Ansatz im Zusammenhang mit den Klassifikationen verfolgt: einen strukturierten JSON-Ex- und Import aller Meta-Daten zu einem Wertpapier in Portfolio Performance inklusive der Klassifikationszuordnung (und auch Logo und anderer Parameter) aber ohne KĂ€ufe, VerkĂ€ufe oder Kurse etc. Damit wĂ€ren dann User in der Lage die eigene mĂŒhsam erstellte Klassifikationen fĂŒr z.B. einen ETF anderen Usern zur VerfĂŒgung zu stellen. Oder User könnten sich das JSON aus eigenen Quellen selbst erzeugen und dann einfach importieren.
Der Weg ĂŒber Portfolio Performance macht ja nur dann Sinn, wenn von dort auch wirklich die Klassifikationen kommen, die sich die User wĂŒnschen und die FlexibilitĂ€t, die mein Ansatz bringen wĂŒrde, eigentlich garnicht gebraucht wird.
Aber auch mein Ansatz krank daran, dass die internen IDs fĂŒr die KlassifikationsbĂ€ume nicht eindeutig sind. Vielleicht muss man erstmal an diesem Problem etwas Ă€ndern.
Ein Nebenthema dabei finde ich noch die Internationalisierung der KlassifikationsbĂ€ume. Ich hab das GefĂŒhl, dass die Anzahl der User, die mit deutschen Klassifikationsnamen nicht glĂŒcklich werde, doch inzwischen recht hoch ist. Portfolio Report stellt ja momentan auch nur deutsche Texte zur VerfĂŒgung, oder gibt es da schon eine Lösungs-Idee?
(Farben liefert Portfolio Report zu den Klassifikationen aktuell auch nicht. Aber die kann man wohl beim Import erzeugen.)
Und noch ein Gedanke zum Mapping der Klassifikationen von P-Report zu P-Performace: als User wĂŒrde ich erwarten, dass fĂŒr die schon jetzt vorhandenen Klassifikationen (insbesondere MSCI-Regionen und Industries GICS) eine nahtlose Integration erfolgt. Bei solchen Standard-KlassifikationsbĂ€umen sehe ich aber auch keinen Grund fĂŒr den User sie strukturell zu Ă€ndern. Wenn z.B. MSCI etwas Ă€ndert, sollte das automatisch (entweder durch ein PP Update oder einen PR-Import) erfolgen. Und etwas anderes als Standard-Klassifikationen wird Portfolio Report ja wohl nicht liefern.
Ich glaube ich muss noch etwas ĂŒber das Thema nachdenkenâŠ
Ich finde den Austausch ĂŒber das Export-Format eine gute Idee. Ich sehe nur die Frage, wo soll der Austausch denn praktisch stattfinden? Im Forum AnhĂ€nge hochladen? Geht aber ist nicht wirklich toll.
Und ich glaube da sind unsere Ideen gar nicht so weit auseinander:
Ich sehe eben Portfolio Report als Austauschplattform. Der erste Schritt wĂ€re da, dass der âTauschâ nur in eine Richtung von PR in die jeweiligen Portfolios geht. Im nĂ€chsten Schritt kann man auf der Website Klassifikationen Ă€ndern (die dann automatisch in die Portfolios kommen) und/oder in PP Klassifikationen Ă€ndern, die dann an den Server gepusht werden und von dort wieder an die Nutzer verteilt werden (die die jeweilige Klassifikation nutzen).
Vielleicht noch ein Satz, weil ich das bislang nicht sauber sprachlich getrennt habe. Unter âKlassifikationâ verstehe ich sowohl den Taxonomie-Baum (z.B. welche LĂ€nder gibt es eigentlich), als auch die Zuordnung einzelner Wertpapiere darin (z.B. wieviel Prozent von dem ETF sind denn in Spanien investiert). Beides sind Informationen, die nicht n mal, sondern nur einmal gepflegt werden sollten.
BezĂŒglich Internationalisierung: Es gibt aus meiner Sicht zwei Lösungen, die Du auch schon beschrieben hast. Entweder PP macht die Internationalisierung ĂŒber den Code (ES = Spanien, Spain oder Espana je nach lokaler Einstellung) oder PR liefert das ĂŒber die API mit. Aus meiner Sicht ist beides möglich. Ich wĂŒrde aber im ersten Schritt nicht alles machen. Mit englischen Texten können vermutlich 80% der Nutzer schon mal was anfangen.
Aber auch mein Ansatz krank daran, dass die internen IDs fĂŒr die KlassifikationsbĂ€ume nicht eindeutig sind.
Sind sie das? Intern haelt ja PP offensichtlich seine eigenen Klassifikationen auch jetzt schon auseinander, inklusive von Usern erstellte. Aus meiner Sicht sollte man die Standardklassifikationen ueber z.B. MSCI und FTSE in PP selbst pflegen und ein eindeutiges Mapping zu solchen Klassifikationen von Performance Report statisch festlegen, alles fest verdrahtet. Alles andere zaehlt als user-defined und arbeitet mit UIDâs, sobald soetwas von aussen hereingereicht wird (oder in der GUI manuell erzeugt wird) .
Internationalisierung der KlassifikationsbĂ€ume [âŠ] die mit deutschen Klassifikationsnamen nicht glĂŒcklich werde, doch inzwischen recht hoch ist.
Ja, ich arbeite selbst auf einem Gemisch, meine eigenen Klassifikationen sind oft englisch, PPâs mitgebrachte sind deutsch. Aber das koennte man in einem Schema mit unterbringen (auch optional mit fallback auf meinetwegen Englisch). Hier einmal ein Link auf eine GICS-Abbildung ueber JSON . Dort koennten ja lokalisierte Varianten der Namen als optionale Attribute im zugehoerigen JSON-Schema mit drin sein (wobei wahrsch. ein XML-basierter Ansatz besser waere, ich habe dunkel in Erinnerung, dass JSON-Strings betreffs Unicode limitiert sind).
Wenn z.B. MSCI etwas Àndert
Der Ferrari waere ein prinzipielles range tag in der Schemadefinition. Zeitintervalle oder zumindest ein Versionierungsschema, die die Gueltigkeit beschreiben, so etwas in der Art (Pseudocode):
# alles Folgende auch einzeln optional
"version":
"number": "1.2.7"
"start_date": 2020-09-17
"end_date": 2022-03-19
Damit koennte auch in der Historie richtig abgebildet werden.
Um das hier auch einmal am Leben zu halten: Durch ein paar andere Schnellschussprojekte dieser Art auf github habe ich jetzt gelernt, wie eine Klassifikation im xml eines PP-Projekts abgebildet wird. Die genannten Programmier-Projekte haben dann ihre Strukturen hart in dieses xml eingepatcht. Das ist nun mehrfach unbefriediegend (zumal auch verschluesselte Varianten dieser xml-Dateien existieren) und laesst mich die FRage einer stabilen API dazu noch einmal in den Vordergrund ruecken. Vielleicht koennte sich der Hauptentwickler von PP auch einmal dazu aeussern. Sonst endet mein Projekt im Ende nicht anders als die anderen Versuche und befriedigt meine unmittelbaren Beduerfnisse ohne einem Normaluser die entsprechenden Mittel an die Hand zu geben.
Ich kann ja mal Sicht erlĂ€utern. Die Kategorien kranken daran, dass sie keinen richtigen âkeyâ haben. Es gibt zwar eine ID. Die ist aber bei jedem User anders. Ohne Key kann man weder Klassifikationen im- und exportieren noch kann man Wertpapier-Zuordnungen zu Klassifikationen ex- und importieren, so dass die Daten ausgetauscht werden können. FĂŒr mich wĂ€re das die Grundlage fĂŒr jede weitere API.
Daher mein erster Schritt hier zu dem ich diese Woche einen Pull-Request bereit stellen werde. Dann wird man weiter sehen.
Du willst also einen key fuer jeden Knoten haben (auch den root einer Taxonomy), richtig? Innerhalb eines trees sollen die keys eindeutig sein, aber nicht zwingend ausserhalb, damit du bequemerweise auch gleich mitgebrachte Dinge wie z.B. die Sector/âŠ/Sub-Industry Nomenklatur (z.B. 60101080) von GICS als key verwenden kannst. In Kombination mit dem root key wird es auch eindeutig. Dem kommt aber dann eine besondere Bedeutung zu und PP muss einen ausreichenden range von root keys erhalten, den niemand benutzen darf, um selbst-verwaltete Taxonomien kontrollieren zu koennen. Ich gehe davon aus, dass das beginnend mit den schon genannten, dann eine wachsende Zahl sein wird/werden kann. Klingt OK fuer mich. Bietet auch weitere Moeglichkeiten, wie Konverter zwischen Taxonomien zu schreiben.
Die Lesbarkeit der Knotenschluessel laesst sich natuerlich auch durch assoziierte [Frei-
]Textfelder erhoehen, die dann an geeigneter Stelle angezeigt werden .
Ja, so in der Art habe ich mir das gedacht. Im ersten Schritt wĂ€re der Key aber kein Pflichtfeld und automatisch wĂŒrde ich den nur dort setzen, wo es sich um original PP Klassifikationen handelt.
Danach könnte man auf der Basis Wertpapiere beim Import und Export klar zuordnen (z.B. â100%,industry-gics,1010â) so dass die Info zwischen Usern ausgetauscht werden kann oder durch andere Programme erzeugt oder verarbeitet werden kann.
Nur einmal als Einwurf, weil ich selbst gerade vor dem Problem stand. Das wird sicherlich in Zukunft kommen. Aber i.M. muss man sicher nicht alles vorwegnehmen wollen.
ich habe fĂŒr mich selbst mal in Java reinschauen wollen und habe ebenfalls eine eigene Implementierung eines Imports von Klassifikationen anhand der vorhandenen ETF umgesetzt.
Diese ist nicht unbedingt die Nutzerfreundlichste, eventuell möchte es aber dennoch jemand ausprobieren und hat Verwendung dafĂŒr.
