Die “eröffnende” Buchung eines Trades darf nicht Null sein, die “schließende” Buchung aber schon. Und so ist das für normale Aktienkäufe auch implementiert (Kauf darf nicht Null sein, die Auslieferung darf Null sein um den “Totalverlust” abzubilden). Und dem Verkauf einer Option sollte es dann auch so sein - die “schließende” Buchung sollte Null sein dürfen - bloß ist es hier die schließende Buchunng der “Kauf”. Warum also nicht auch solche Käufe erlauben?
Ich will diese Einschränkung beim Kauf nicht ändern. Ich muss jetzt schon so viel “Gymnastik” machen weil Leerverkäufe abgebildet werden. Das wirkt sich an verschiedene Stellen aus, z.B., wie Buchungen mit und ohne Uhrzeit an einem Tag sortiert werden um gültige Geschäfte sicherzustellen. Außerdem glaube ich, dass es dann auch für andere Dinge verwendet werden würde. Gratisaktien sind kein Kauf zu Null Euro - es ist Alternative Form von Gehalt. Und das macht es dann mathematisch kaputt - abgesehen von den Supportfragen hier im Forum.
Was könnte man also machen? Ich glaube mittelfristig bräuchte es einen Typ “Instrument”. Ein Wertpapier wäre ein Typ, Option ein anderer. Ich weiß aber auch, dass das keine triviale Änderung im Code ist. Ich müsste auch selber Optionen besser verstehen um das beurteilen zu können. Es ist zugegebenermaßen auch nicht ganz oben auf meiner Liste, weil ich den Eindruck haben das es auch nur einen Teil der PP Benutzer betrifft.
BTW, hast Du diesen Post gesehen:
Wenn ich das richtig verstanden habe, werden hier die Buchung in Käufe mit 0,01 umgewandelt. Das wäre zumindest eine Möglichkeit die Position zu schließen (und könnte man auch im Importer unterstützen).
Wenn man Optionen wirklich abbilden möchte miss das wirklich gut überlegt werden. Schließlich gint es auch Aktien gedeckte Optionen.
Ohne Stift und Papier wird das maximal schwierig.
Dann würde ich zunächst eine PR anbieten, damit die IBKR Nullwert-Käufe importiert werden. Hast du da einen Tipp, ob Lieferung oder Kauf für 0,01 die bessere Wahl ist? Soweit ich sehen kann, gibt es bei Lieferung keinen Nachteil, sodass ich dazu tendiere.
Der Skript bleibt eine Option, aber es wäre noch besser wenn es mit PP klappt.
Einlieferung - man will ja den Wert nicht auf dem Konto habe.
Zu dem PR: der Importer kann aktuell nicht entscheiden ob Einlieferung oder Kauf - das macht der Nutzer. Das könnte man in einem zweiten Schritt ermöglichen. Und ich denke der Benutzer sollte irgendwie eine Option haben - z.B. das die Buchungen mit einem Hinweis versehen sind und per default nicht importiert werden.
TL/DR: Ich habe interesse an dieser Diskussion über verbesserter Behandlung von Optionsverkäufen in PP durch IBKR import.
Danke schonmal @georgemac-labs und @AndreasB . Die Diskussion ist sehr informativ und ich habe jetzt meine IBKR Options Verkäufe besser abgebildet als vorher.
Ich bestätige, dass eine Einlieferung für 0,01 gut funktioniert.
Ein PR wäre super. Die vorgeschlagene Verbesserung würde mir Zeit sparen, manuell die Optionspositionen zu schließen.
Ich habe zum Testen von Optionsverkäufen ein Papiergeldkonto bei IBKR benutzt. Ich kann anbieten die IBKR FlexQuery XML Datei zu teilen, falls es beim Testen hilft. Gerne teste ich die neue Funktion auch selbst, sobald sie verfügbar ist.
Ich habe auch noch ein paar weitere Ideen, wie PP den Optionshandel besser abbilden kann. Aber, ich halte mich erstmal zurück weil (1) ich vermute, dass ihr auch schon viele gute Ideen habt und (2), wie schon @georgemac-labs schrieb :
Problem ist halt, dass man beim Schreiben von Optionen einen Verkauf durchführt, ohne dass es einen vorigen Kauf gab. Daher habe ich schon vor einiger Zeit einen Vorschlag gemacht, wie man das eventuell mit überschaubarem Aufwand abbilden kann (und dabei auch Dinge wie Leerverkäufe und Zinseinnahmen für Aktienverleihen, etc. erschlagen könnte):
Ich möchte zum Thema Optionen zurückkommen, aber zwischendurch eine Frage zum Konzept für Stock-Splits.
Ich glaube ich habe nie eine gute Dokumentation zur Konfiguration des Flex-Querys gefunden und deswegen hatten meine Exports nicht alle Datentypen, die unterstützt sind – z.B. die CorporateActions haben gefehlt. Mir ist aber aufgefallen, dass die Bestände nicht gestimmt haben und ich habe die Splits händisch eingetragen.
Nun habe ich geprüft was der Importer kann, meine Query angepasst, alles neu generiert und importiert … und jetzt habe ich auch die Delivery Transaktionen also Doppel-Splits
Ich kann die Fehler leicht korrigieren, aber mich interessiert:
Ob’s hier Pro und Contra gibt und was empfohlen ist? Lieber über Split oder Delivery abbilden?
Warum der Importer nicht das Split Feature verwendet? Vielleicht weil es schwer ist, die richtige Parameter aus der XML zu erkennen?
Nach etwas Recherche, versuche ich meine eigene Frage zu beantworten – für den Fall, dass es Anderen künftig hilft!
Für den IBKR-Kunden, gibt es zwei Ansätze für Splits: Stock Split Wizard und IBKR Import von CorporateAction Elementen.
Beide haben Pro und Contra
Das Prinzip vom Stock Split Wizard ist, bewusst die Historie zu verfälschen, als hätte es den Split nie gegeben. Also für Transaktionen vor dem Split, werden die tatsächliche Aktienmengen mit Post-Split Werten überschrieben.
Importiert man die CorporateActions, werden Lieferungen erzeugt. Dann ist die Aktienmenge zu jedem Zeitpunkt in der Historie korrekt, aber dafür gehen Berechnungen kaputt (z.B. FIFOs können zu falschen Ergebnissen führen, wenn man den Split als Lieferung betrachtet)
Bei Portfolio Performance geht’s für mich um Analyse, nicht die Buchhaltung. Daher ist mein Rückschluss: Verwende das Stock Split Wizard.
Die Kontoumsatz-Query funktioniert anstandslos und importiert alle Daten korrekt. Aber die Handelsbestätigung bekomme ich nicht zum Laufen. Leider gibt das System aber auch nicht aus, was genau das Problem ist, sondern sagt nur “Fehlermeldungen”.
Ich habe mir das Manual angesehen, finde aber auch keine schlüssige Erklärung. Ich habe versucht alle Felder anzuschalten, selektiv abzuwählen, aber nichts hat geholfen. Bei meiner Recherche habe ich Angaben erhalten, dass die Formatierung der Datei ein Problem sein könnte, also Datumsformat, Zeitangabe und Semikolon. Leider widersprechen sich die Angaben.
