Interactive Brokers

Hi Leute :wave:

Ich habe gerade den CFD-Import eingebaut, bin mir aber nicht ganz sicher wie die Werte richtig eingelesen werden sollten:

  1. So wie das „underlying“ tatsächlich bewertet wird (Im Fall von IBDE30 aktuell 13.336 EUR)
    • Performance-Metriken werden auf Basis von Fremdkapital ermittelt
    • Mein Portfolio enthält Fremdkapital
  2. So wie es gebucht wird (nur die Gebühr)
    • Mein Portfolio-Saldo stimmt
    • Ich erziele den Gewinn/Verlust mit 0 EUR Einsatz. Rendite => unendlich

Die Marge wird leider nicht ausgewiesen. Sonst könnte man das verwenden.
Wie ist eure Meinung?

Bin (leider) kein Entwickler - aber ich wäre SEHR daran interessiert, dass die CFDs beim IB-Import auch funktionieren.

Info am Rande bei derzeitigen Import: Interessanterweise bucht PP bei mir die täglichen Dividendenzahlungen, die man erhält, wenn man z.b. einen IBUS500 CFD hält, nicht aber den IBUS500 CFD selber.

[Die im folgenden enthaltenen Gedanken eines naseweisen Neulings bitte als konstruktive Kritik verstehen.
Über den Interactive-Brokers-Import hinausgehende Diskussionen sollte sicher in einem anderen Thread (Thema) passieren; wie z.B. darüber
- ob die „Dokumentation“ zum PP-Projekt nicht vielleicht etwas zu knapp und verstreut ist
- ob ein Wiki-Ansatz sinnvoller wäre, als die How-Tos im Forum.]

@turbodackel
Wenn die „Erwartungen“ des CSV- oder XML-Imports („Activity Flex Query“) dokumentiert wären, könnte man unabhängig von PP (in beliebiger Programmiersprache) je Broker-Quelle einen Konverter zur Verfügung stellen.

Python macht sich sicher besser als Java für das, was Du da händisch gemacht hast, z.B. je Währung zu splitten.
Ein großer Fortschritt wäre, wenn PP verschiedene Währungen in einem Depot verstehen würde (wie reale Depotkonten auch). Die Währung global zu konfigurieren ist aus meiner (Anfänger-)Sicht kontraproduktiv.
Die Struktur der „depot.xml“ (das PP-Datenmodell) ist wahrscheinlich zu komplex, als dass man das jedesmal neu erzeugen (und Änderungen über die Versionen nachpflegen) wollte.

Ich glaube, da hast du ein ganz großes Mißverständnis. Nur die Währung, in der du die Ergebnisse angezeigt bekommst (Berichtswährung), ist global; und auch die kannst du jederzeit kurzfristig umstellen.

Konten kannst du in beliebigen Währungen anlegen, und in einem Depot können völlig unterschiedliche Wertpapiere sein auch mit Kursen in diversen Währungen.

Die How-Tos im Forum sind größtenteils Wikis; zu erkennen am grünen Hintergrund.

Das ist bestimmt so. Um es zu ändern, muß aber jemand (= du) mehr Dokumentation verfassen und besser ordnen.

2 Likes

Warum müssen dann IB-Nutzer wie @turbodackel diese Kopfstände beim Import machen? Ich konnte solche „Falsche Währung“-Fehler beim Import von „Flex Query“-xmls auch nur durch Anlegen von separaten Depots in PP je Währung verhindern.

Depots haben keine Währung in PP, daher kannst Du auch keine separaten je Währung anlegen. (Du kannst natürlich welche anlegen und die Währung in den Namen schreiben, aber das hat dann keinerlei Funktion.)

Da Du auch von der „depot.xml“ schreibst, vermischst Du Depots mit Dateien? Eine Datei ist das Äquivalent eines Portfolios, das mehrere Depots enthalten kann.

„depot.xm“: Ja, sorry, korrekte Begriffe sind natürlich gerade bei solchen komplexen Sachen wichtig. Ich meinte das xml, dass man exportieren kann, um PP von Null zu füllen (hatte nur ein paar mal bei anderen „depot.xml“ gesehen) intern wohl <client/> und in der Annahme, dass das ziemlich direkt das interne Datenmodell abbildet – und dass es wahrscheinlich sinnlos aufwändig wäre, dieses xml aus den bei einem Broker (wie auch immer) exportierten Daten korrekt zu erzeugen – statt PPs Importmöglichkeiten zu nutzen, die allerdings begrenzt sind und z.B. wegen der fehlenden Währung im PP-Depot u.U. eine Menge Handarbeit erfordern.

Zum eigentlichen Punkt: Man muss also wirklich je Währung ein PP-Depot haben, um IB-Trades importieren zu können, oder?

@Damian: Ich glaube turbodackel meint die FlexQuery XML von IB und nicht die von XML von PP, die er händisch anpasst. Denn es werden ja nur Transaktionen hinzugefügt und nicht das Depot komplett neu aufgebaut.

Mit der Thematik hier habe ich mich noch nicht tiefergehend befasst, kann aber sagen, dass es beim PDF Import so ist, dass man einige Dinge beachten muss, wenn Transaktionen importiert werden, die nicht der Kontowährung entsprechen. Z.B. den Bruttowert in beiden Währungen korrekt zu berechnen oder die Steuern und Gebühren in die Kontowährung umzurechnen. Vielleicht muss hier auch noch beim IBFlexStatementExtractor nachgebessert werden. Aber wie gesagt, damit habe ich mich noch nicht wirklich befasst.

Theoretisch ist alles, was Du manuell buchen kannst auch über den Import möglich (wenn alle notwendigen Daten vorhanden sind und der Importer sie korrekt deuten und verarbeiten kann). Probiere doch mal aus, ob sich die Transaktionen manuell buchen lassen. Wenn das geht, stellt sich die Frage, ob im XML Export von IB alle notwendigen Informationen enthalten sind. Und wenn auch das passt, muss „nur“ noch der Importer angepasst werden. :wink:

Danke, das hatte ich schon so verstanden und der Import funktioniert ja, wie @turbodackel es beschrieben hat.
Meine Frage war: Muss es in PP ein Depot pro Währung sein, wenn man die Trades in der beim Broker geführten Währung sehen möchte (und nicht alles nach EUR konvertiert)?

(…Nach meinem bisherigen Verständnis muss man bei z.B. 5 Währungen im Depot und monatlich exportierten Trades das Flex-Query-XML in 5 Dateien aufspalten und in PP 5-mal Import klicken.
→ again: feature request for CLI :relaxed:)

Hallo,
von meiner Seite einige Anmerkungen zum IB Import.

  • Importiert werden, wie schon korrekt angemerkt wurde, nur Dividenden, Käufe, …
    Forex, Gebühren und Zinsen mache ich per Hand. Das sind 4-5 Buchungen im Monat. Kann ich mit leben.
  • In der von IB generierten FlexQuery passe ich vor dem Import einmal die Währung an. Dann importiere ich die Transaktionen. Danach nehme ich die nächste Währung für die im FlexQuery Transaktionen vorhanden sind usw. Kann ich auch mit Leben. Hierbei gehts es schon um eine deutlich 2 stellige Anzahl Buchungen/Monat.
  • Nach dem Import führe ich händisch bei Dividenden die Dividenden und die Steuerbuchung zusammen. Das ist nicht so schön :unamused:

Das mit den Währungen ist, soweit ich es verstanden habe, nicht so einfach zu lösen, da beim Import eine Konto für die Buchungen ausgewählt wird. Und da kommen dann die Währungen ins Spiel. D.h um Buchungen mit verschiedenen Währungen zu importieren, müssten auch mehrere Verrechnungskonten angegeben werden. Sprich Programmieraufwand.

Die Steurbuchungen direkt in die Dividende zu integrieren, scheint auch keine triviale Problemstellung zu sein. Sprich Programmieraufwand.

Da mir aktuell die Zeit fehlt, mich in den Quellcode einzuarbeiten, benutze ich es so wie es aktuell implementiert ist. Und Bedanke mich hiermit noch einmal bei den Entwicklern, die diese Lösung realisiert haben. :+1:

Sollte es meine freie Zeit erlauben, arbeite ich mich gern einmal in den Code ein.
Vielleicht wäre auch ein universeller Import per CSV, XML oder JSON in PP der bessere Weg. Und dann dazu einen Konverter, der die Daten aus den verschiedenen Quellen (IB FlexQuery, Broker Export per CSV (das können ja einige Banken auch), entsprechend in dieses Format wandelt.

Kann der aktuelle CSV Import eigentlich schon mit mehreren Konten beim Import umgehen? Habe mir das noch nie angesehen.

Hallo Damian,

Meine Frage war: Muss es in PP ein Depot pro Währung sein, wenn man die Trades in der beim Broker geführten Währung sehen möchte (und nicht alles nach EUR konvertiert)?

Nein. Ein Depot reicht. Das Depot kennt keine Währung. Nur Wertpapiere.

Aber für die „realen“ Buchungen (Kauf, Verkauf, Dividende, Steuer, …) brauchst du ein Verrechnungskonto. Und das hat eine Währung.
Das Konzept in PP sieht aktuell pro Depot ein „fest zugeordnetes“ Verrechnungskonto vor (eher eine lose Bindung, aber bei der Depotkonfiguration anzugeben).
(Als Andreas das Programm für seine Zwecke konzipiert hat, war diese Festlegung auch vollkommen OK. Die Anforderungen an PP sind im Lauf der Zeit schon ganz schön gewachsen :wink: )

Bei der konkreten Buchung kannst du dann das Verrechnungskonto, auf dem die eigentliche Geldbewegung landen soll, aus.

Als Beispiel das Verhältnis Depot:Verrechnungskonto ist in meiner PP Datei glaube ich 1:2. Sprich doppelt soviel Verrechnungskonten wie Depots.

Ulrich

Hallo,

wo ich das mit der nativen Schnittstelle für einen Import in PP gerade erwähnt habe:
Gibt es eventuell die Möglichkeit, das per Plugin/API/was auch immer Plattform Übergreifend zu lösen?
Vielleicht in der Form, das dort auch Script/Shell Interpreter eingesetzt werden können?

Wer Alfred auf macOS kennt, weiss was ich meine.

Ulrich

…da bräuchte man erst einmal ein CLI (s.o. „feature request“ #155).

In diese Richtung ging mein „wenn CSV- oder XML-Imports dokumentiert wären…“ in #149.
Es gibt ja eine einen CSV-Import, der hoffentlich für das regelmäßige Einpflegen der Trades und Dividenden ausreicht. Bei Buchungen importieren hört das Handbuch aber leider auf, sollte man (ich) also den Code befragen oder ist das „Buchungen-CSV-Format“ irgendwo dokumentiert?

Verstehe ich nicht. Ich kann einem Depot („securities account“, ohne Währung) nur ein Verrechnungskonto („deposit account“, mit Währung) zuordnen.
Dein IB-Depot (Flex Query) kennt aber EUR und USD in den Buchungen: Das packst du über 2x importieren in dasselbe PP-Depot?

[Ich brauche je ein Paar Depot+Konto (securities+deposit accounts) pro Währung um so ein Flex Query XML mit mehreren Währungen ohne Fehler zu laden.]

Leg doch einfach mal ein Depot an mit einem verknüften Konto z.B. in EUR (vermute mal, das ist auch die Steuerwährung) und ein zweites separates Konto in USD und nimm ein USD und ein EUR Wertpapier und erstelle Buchungen. Dabei kann man die Buchung auf ein beliebiges Konto vornehmen. Hier ein Beispiel (sogar mit drei verschiedenen Konten):

Vielen Dank! Diese Gegenkonto-Spalte hatte ich nicht gesehen (blieb zu schmal) und im CSV-Export wird sie weggelassen.
Geht also doch, nur ein PP-Depot für Transaktionen mit unterschiedlichen Währungen zu tracken – hatte ich wegen der Fehlermeldungen des Interactive Brokers XML-Imports falsch interpretiert.

Bleibt die Frage, wie man für den CSV- oder XML- Import von Buchungen (Trade / Dividend) das fehlende Mapping Buchungswährung->Gegenkonto konfigurieren kann – bzw. solange das für die Währung eindeutig ist – ob man nicht pro importierte Buchung das Gegenkonto automatisch setzen kann?
…statt den Fehler „Transaction currency USD does not match account currency EUR“ zu werfen.

Verstehe ich nicht. Ich kann einem Depot („securities account“, ohne Währung) nur ein Verrechnungskonto („deposit account“, mit Währung) zuordnen.
Da habe ich mich unverständlich ausgedrückt: Gemeint war; mein PP Datei enthält z.B. 8 Depots aber insgesamt 15 Verrechnungskonten. Ich habe 2 Depots, in denen WP für 6 verschiedene Währungen auftauchen.

Ein Weg wäre, eine 1:n Zuordnung mit den Verrechnungskonten zu Depot. Sprich pro Währung ein Konto zuordnen. Dann könnte der Import das automatisch zuordnen.
Das würde auch einige Auswertungen und Filter stark vereinfachen.
Möchte ich die Erträge/Gebühren/… für ein Depot ermitteln, muss ich einen Filter mit allen Verrechnungskonten die Buchungen dieses Depots enthalten, erstellen. Kein großer Aufwand, da die Konten/Depots nicht so häufig wechseln.
Führt aber schon mal zu Unstimmigkeiten, wenn ein neues Verrechnungskonto hinzu kommt. Dann muss auch der Filter erweitert werden, damit wieder alles passt.

4 Beiträge wurden in ein existierendes Thema verschoben: Wiki für Portfolio Performance

https://forum.portfolio-performance.info/t/interactive-brokers/276/148?u=marom300

Hi Michel,
ich bräuchte diese Funktion (CFD-Import) ebenfalls. Wie bekomme ich die denn eingebunden?
lg