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.
@Guiniviere bei deinem Import-Screenshot ist kein Problem sichtbar. “Fehlermeldungen” ist eine Überschrift. Es werden scheinbar keine Transaktionen gefunden und entsprechend gibt es keine Fehler.
Ich denke, dein Export ist nicht richtig konfiguriert. Es hat bei mir auch eine Weile gedauert, die ganzen Häkchen richtig zu setzen. Ich habe m.M.n. keine korrekte Dokumentation gefunden – ich weiß nicht, ob es die jetzt gibt.
Hier ist was ich habe. Leider ist die Konfiguration noch komplexer denn jedes Kästchen ist anklickbar mit 100 weiteren Häkchen drunter, aber bei mir sind fast alle davon gesetzt.
Muss nochmal zu dem Thema „Verkauf zu 0€“ kommen. Bei mir betrifft es Optionsscheine die zu 0,00€ verkauft / ausgebucht werden, sprich Totalverlust. Ohne das Thema Optionen anzufassen sollte das doch möglich sein?
Ich nehme bei IBKR am ‘Stock Yield Enhancement Program’ teil und mir wurde ein Teil der Dividende als normale Dividende und der andere Teil als ‘Payment in Lieu (PIL) of a dividend’ ausgezahlt.
In der Flex Query werden beide Dividenden separat aufgelistet und für beide Dividenden wird auch jeweils separat die Steuer aufgeführt.
Beim Import wird die Steuer für die ‘normale’ Dividende auch dieser Dividende zugeordnet. Die Steuer für die ‘Payment in Lieu’ Dividende wird hingegen separat eingebucht, so dass ich drei Buchungen habe: Die normale Dividende (incl. Steuer) , die ‘Payment in Lieu’ Dividende (ohne Steuer), und die Steuer für die ‘Payment in Lieu’ Dividende.
Am liebsten wäre mir, wenn ich nur eine Buchung hätte bei der die beiden Dividenden-Arten aufsummiert sind und auch die beiden Steuern zusammen aufgeführt werden.
Alternativ zwei separate Buchungen für die beiden Dividenden-Arten, bei der aber die Steuer für die ‘Payment in Lieu’ Dividende bei der ‘Payment in Lieu’ Dividende Buchung aufgeführt wird.
Es gibt ja keine Möglichkeit wie bei PDF Dokumenten einen anonymisierten Debug einzustellen. Welche Informationen soll ich statt dessen liefern?
Das Format ist aber ein reiner Text, d.h. du kannst da mit jedem beliebigen Editor die identifizierenden Teile entfernen. Auf GitHub kannst du dir ja mal anschauen, wie die XML-Dateien anonymisiert wurden:
<AccountInformation>..</AccountInformation> ist komplett entfernt
Alle accountId-Attribute wurden mit einem Dummywert gefüllt (d.h. eine Textersetzung von deiner echten Account-ID zu U123456)
Das sind eigentlich recht überschaubare Anpassungen.
Edit:
Ich hatte dieses Jahr auch eine “Payment in lieu of Dividend”-Zahlung. Auf Quellensteuerseite sehe ich da aber nur einen Steuerabzug, nämlich für den Teil der Aktien, die zu dem Zeitpunkt nicht verliehen waren. Schau nochmal genau hin, ob es da wirklich einen Steuerabzug dafür gibt.
Vielen Dank. Du hast recht, das Anonymisieren ist in der Tat nicht viel Arbeit. Ich werde die Datei anfügen.
Bei mir gibt es wirklich einen Steuerabzug für ‘Payment in lieu of Dividend’. Der Eintrag hat auch eine spezielle Bezeichnung in der FlexQuery, ‘PAYMENT IN LIEU OF DIVIDEND - US TAX’.
Nach dem Import sieht es dann folgendermassen aus:
