Ganz dickes Lob an die Entwickler. Gerade den Juni bei Import eingelesen. Alle Buchungen wurden in einem Rutsch importiert.
1 Like
Geht es um das komplette Depot? Also alles aus Depot A in Depot B migrieren?
Wenn ich überlegen sollte was zu bauen.
Ja genau darum geht es?
Wie gesagt, ich glaube ich würde alle Buchungen von IBKR aus PP raushauen und einfach neu in PP einlesen.
10 Jahre, 10 Flex-Querys, halbe Stunde maximal
1 Like
Bei mir taucht den gleichen Fehler auf. Gibt es ein Workaround oder Bugfix geplant?
Ja - funktioniert sehr sehr gut - gerade mit verschiedenen Konten. Riesen Erleichterung im vergleich zur vorherigen Version!
Hallo,
erstmal vielen Dank an alle Beteiligten, das jetzt auch FX Transfers mit importiert werden können.
Mir ist trotzdem noch ein Bug aufgefallen. Beim Import von Dividenden wird für das Datum das Feld „reportDate“ benutzt. Damit PP mit dem Kontoauszug übereinstimmt wäre das Feld „dateTime“ oder „settleDate“ besser. Bei manchen habe ich da größere Differenzen. Schöne wäre auch die negativen Dividenden mit zu importieren und das Feld „description“ in PP Notizen zu importieren.
Vielen Dank
Aus neugier, was sind negative Dividenden?
Ich vermute Stornos
Ah, so weit wollte mein Hirn gerade nicht. Danke, macht Sinn.
@Adamski Stornos werden mit an Sicherheit grenzender Wahrscheinlichkeit in naher Zukunft nicht automatisch importierbar sein.
Richtig, sind Stornos. Weiß auch nicht warum IB bei mir häufig Dividenden (oder auch andere Buchungen) erst verbucht dann wieder storniert und neu verbucht. Wenn halt die negativen Buchungen mit importiert werden, benötigt es keine manuelle Suche und Nacharbeit.
@Sn1kk3r5 was spricht gegen den Stornoimport? Als Nichtwissender würde ich sagen das ist „nur“ ein Vorzeichenthema.
Genau, dass es sehr komplex ist, dass zu entwickeln, dass es in 99,9% der Fälle funktioniert:
Zum einen kennt der Importer zum Zeitpunkt des Imports die zu korrigierende Buchung nicht.
Zum anderen werden Dividenden gerne gestückelt was die Identifikation zusätzlich erschwert.
Und dann kann es passieren, das du für eine Dividende 4 Stornos bekommst.
Wie soll man damit generell umgehen?
Ich vermute du hast REITS oder andere Firmen die ihre Dividende mal mit und mal ohne bzw. reduzierter Steuer auszahlen. Das kann aus steuerlichen Gründen immer erst im Nachhinein korrigiert werden.
Nach welchem Schema versucht der Importer Dividenden und Steuern zusammen zu fügen? Datum? Habe hier eine Aktie bei der in der xml das Feld „dateTime“ und „reportDate“ um einige Monate abweichen. Wobei das Feld „dateTime“ mit dem Kontoauszug übereinstimmt und ich in PP das Datum aus „reportDate“ finde.
Müsstest du auf github im passenden importer schaun.
Einer der Punkte, der die Grenzen des Importers zeigt. Ich habe mehrere WP die mehrere Ausschüttungen an einem Tag vornehmen. Meist normale Dividende und RoC. Eine mit und eine ohne Steuern.
Hier passiert es oft, das die Steuern der falschen Buchung zugeordnet werden. Das kann der Importer nur auflösen, wenn er auch den Kommentar auswertet. Oder mit sehr viel Aufwand feststellen, das solche Buchungen vorhanden sind, und die Zuordnung dann von Hand vornehmen.
Ähnliches passiert dann bei Stornos. Auch da müsste er erst alle Informationen inkl. der Kommentare auswerten um eine korrekte Zuordnung hinzubekommen.
Ich finde es schon absolut super, das die Entwickler es hinbekommen haben, das die Steuern direkt den Dividendenbuchungen zugeordnet werden. Ein Riesenfortschritt zu den ersten Versionen des Importers, die das jeweils als Dividende und Steuer in 2 Buchungen verbucht haben. Vielen Dank dafür.
1 Like
Habe durch manuelles korrigieren der .xml den Importer soweit „überlistet“ dass er die Dividenden jetzt korrekt einliest und zuordnet. (Merkmal Feld „reportDate“)
Nochmal meine Anfrage, bitte das Feld „dateTime“ mit der Uhrzeit beim Import auszuwerten.
Dann kann man bei Dividenden die am selben Tag ausgeschüttet werden manuell die Uhrzeit manipulieren und sie werden am richtigen Tag zugeordnet. (Dividende + Steuer)
Hallo zusammen, wie andere Nutzer vor mir habe ich Probleme mit IBKR Optionshandel. Genauer gesagt werden abgelaufene Optionen nie geschlossen, wodurch „Zombie“-Positionen im Portfolio offen bleiben.
Die Lösung hierfür ist aber bereits in der Datei von IBKR – es gibt Transaktionen, um diese Positionen zu schliessen! Sie werden nur blockiert weil der Wert der Transaktion Null ist. Ich bin nicht überzeugt, dass Null-Wert Transaktionen grundsätzlich verboten werden sollten. Dies ist nach meinem Verständnis ein üblicher Mechanismus, um solche Positionen zu schließen.
Ich habe verstanden, ein Bedenken war, dass diese zu irregulären pro Wertpapier IRR/TWROR Werten führen. Laut meiner Recherche sind solche Metriken für einzelne Optionen knifflig. Wir gehen von einem Barkonto aus* …
Longs sind unkompliziert: Anfangswert/Anfänglicher Zahlungsstrom für IRR/TWROR ist einfach die gezahlte Prämie. Aber beim Schreiben einer Option, sollte man den Nominalwert (d.h. die vollen Andienungskosten) verwenden. Die IBKR-Daten reichen hierfür: strike x multiplier.
Also für korrekte Werte müsste man m.E.:
-
Datenmodell erweitern
-
Optionen differenzieren
-
Call und Put differenzieren
-
Strike & Multiplier speichern
-
Wenn man schon dabei ist, könnte man ggf. auch Expiry speichern für künftige Funktionalität.
-
-
Sonderfälle in den Berechnungen implementieren
Das klingt für mich gut machbar. Aber wer Optionen schreibt wird nur bedingt geholfen, denn Schreiben einer Option wäre immer profitabel. Im Falle von Verlust wird dieser nämlich bei der Aktie gebucht. Deswegen müsste man eigentlich diese als einzelne Handelskampagnen auswerten und da geht ein neues Fass auf…
Ich wäre bereit die Basisversion (ohne Handelskampagnen) zu implementieren, aber erst muss ich wissen, ob man überhaupt PP Datenmodell und Logik wegen Optionen erweitern möchte?
Als Plan B, finde ich inkorrekte IRR/TWROR Werte für Optionen vertretbar! Denn ohne Handelskampagnelogik hat man sowieso unsinnige Werte. Ich finde es viel wichtiger, dass die Bestände korrekt und zombiefrei sind. Und nach meinem Verständnis, sollten aggregierten IRR- & TWROR-Werten (z.B. für das Portfolio) trotzdem stimmen.
Oder Plan B2: Man könnte Options-Trades erkennen und für diese keine IRR/TWRORs anzeigen (ggf. mit Mouseover Tooltip, um die Lücke zu erklären).
Ich möchte auf jeden Fall das Prinzip “Fortschritt vor Perfektion” vertreten. Insbesondere bei FOSS sind inkrementelle Verbesserungen eher machbar. In https://github.com/portfolio-performance/portfolio/pull/4825 sieht man die Problematik wenn man versucht, alles auf einmal zu lösen: Riesige PR und die Arbeit ist scheinbar versandet.
Als Ausgangspunkt habe ich eine PR für Plan B erstellt: IBFlex import zero value option expiry transactions by georgemac-labs · Pull Request #5201 · portfolio-performance/portfolio · GitHub
@AndreasB @Nirus können wir hier einen pragmatischen Kompromiss finden?
Ich freue mich auf euer Feedback.
* Bei Marginkonto sollte man mit Einschussforderung arbeiten, aber ich denke PP unterstützt Margin generell nicht, also den Fall ignoriere ich
Aktuell ist es so:
Ein Kauf (oder Einlieferung) darf keinen Wert von Null haben. Das Problem bei solchen Käufen ist nämlich wenn die Position später einen Wert hat. Dann ist die Performance mathematisch immer unendlich. Nichts ist plötzlich etwas Wert: 1 / 0.
Ein Verkauf darf keinen Wert von Null haben (es wird nichts auf dem Konto verbucht).
Eine Auslieferung darf einen Wert von Null haben (es ist ein Totalverlust).
@georgemac-labs Ich frage mich ob der Importer nur in diese Richtung erweitert werden müsste? Es ist doch ein Verkauf von Optionen, oder?
Vielleicht noch mal zu den Begrifflichkeiten “Verkauf” und “Auslieferung” (heute würde ich das so nicht mehr machen…): “Verkauf” ist eine Buchung auf dem Depot und eine Buchung auf dem Konto, d.h. das Geld verbleibt im Portfolio. “Auslieferung” ist nur eine Buchung auf dem Depot. Es ist im Prinzip auch ein Verkauf, das Geld wird aber gleichzeitig entnommen.
Aktuell verhalten sich die Importer wie folgt: es werden immer Kaufe/Verkäufe extrahiert. In dem Import Dialog, kann der Benutzer entscheiden, ob das als Kauf/Verkauf oder als Einlieferung/Auslieferung importiert wird. Wir müssten die Logik also dahingehend erweitern, dass der Importer Verkäufe mit Null erfassen darf, die aber immer als Auslieferung importiert werden.
Ich denke mittlerweile, dass mittelfristig PP mehr Typen kennen muss. Auch eine Anleihe mit den angefallenen Stückzinsen ist aktuell nur bedingt abbildbar. Aktuell gibt es im Prinzip schon drei Typen: Wertpapier, Indices (= haben keine Währung), Wechselkurse (= haben ein Währungspaar). Allein, dass ist eine nicht triviale Änderung.
1 Like
@AndreasB sorry, das war vielleicht nicht gut erklärt!
Mein Hauptproblem entsteht durch das Schreiben von Optionen. Das sieht so aus:
- Ich schreibe (verkaufe) eine Option, wo ich aktuell Null besitze
- Ich erhalte Geld und habe nun eine negative Position für diese Option
- Falls die Option wertlos ausläuft, wird die Position gutgeschrieben und dabei fließt kein Geld
Also dein Szenario kommt doch vor: Kauf für nichts, Verkauf für Geld … nur andersrum 
Das ist die Natur von Shorting.
Wie du sagst, rein aus der Cashflow Perspektive, gibt es für diesen Ablauf z.B. keinen validen IRR. Das ist kein Bug und kein Problem – das ist eine mathematische Wahrheit. Ich habe nichts investiert und Geld bekommen.
Die fachliche Lösung: Man verwendet für Shorts nicht die Cashflow-Perspektive. Weil diese das Geschäft nicht gut erfasst und unsinnige Werte hergibt.
Ich nehme die CFA Institute Global Investment Performance Standards (GIPS) als Quelle, um die Aussage zu belegen. Sie nennen es eine “Overlay Strategy”, sofern man nicht direkt für die Position bezahlt sondern, man hinterlegt Kapital/Margin als Versicherung (daher Cash-Secured Put genannt). Im Guidance Statement On Overlay Strategies wird erklärt, wie man Performance für solche Strategien berechnet:
“Overlay exposure … is the notional value of the overlay strategy being managed, the value of the underlying portfolio being overlaid, or a specified target exposure.” – Seite 4
“Calculating returns for overlay strategies requires special care… The return for an overlay strategy is the investment performance [Profit/Loss] divided by the overlay exposure.” – Seiten 11-12
Also schreibt man z.B. ein Cash-Secured Put, ist der Anfangswert für die Performance-Berechnung nicht Null (der Cashflow), sondern die vollen Andienungskosten. Denn dieses Kapital ist belegt für den Fall, dass der Put-Verkäufer andienen muss. (Bei einem Marginkonto verwendet man die Einschussforderung, aber wie gesagt – PP kennt Margin meines Wissens nicht. Dieses Fass würde ich nicht jetzt aufmachen…)
Also die Bedenken über Performance-Werte sind valide, aber aus meiner Sicht liegt die Lösung in einer Erweiterung der Berechnungen.
Ich kann gerne den Importer anpassen, sodass Nullwert-Transaktionen als Lieferungen erfasst werden, aber ist das nicht ein Hack bzw. semantischer Missbrauch? Ich dachte, Lieferung ist definiert als: Das Asset bleibt im Eigentum, aber wird anderswo übertragen. Das ist ja hier nicht der Fall.
Manchmal werden Positionen wirklich kostenneutral geschlossen und es ist meines Wissens üblich, dass Broker diese als Kauf/Verkauf für Null modellieren. Weiteres Beispiel: Long oder Short Aktie Position, Firma wird Pleite, Broker bucht Verkauf bzw. Kauf der Position für Null.
Was die Performance-Werte angehen, fände ich den Plan B2 oben ein pragmatischer erster Schritt: Positionen/Trades erkennen wo PP keine korrekte Berechnung machen kann und die Werte ausblenden. Perspektivisch könnte man diese Berechnungen erweitern.