Das kann aber so doch nicht stimmen. Bei mir geht es um ein Wertpapier, das teilweise schon mehrere Depots durchlaufen hat. Wenn ich bei diesem Wertpapier einen Verkauf von 20 Anteilen hinzufüge wird korrekt nach FIFO vorgegangen. Wenn ich bei dem gleichen Wertpapier stattdessen diese 20 Anteile umbuchen möchte werden Anteile die mittendrin (in dem aktuellen Depot) angeschafft wurden umgebucht. Das ist für mich ganz klar ein Bug.
Ich zeige das mal anhand von Bildern. Folgende Daten sind hinterlegt:
So sieht der Rest aus nachdem ich 20 Anteile verkauft habe. Es wurden korrekt die ältesten 20 Stück nach FIFO verkauft:
Und so sieht es aus wenn ich nicht 20 Anteile verkaufe sondern 20 Anteile umbuche, hier sind ältere weiterhin vorhanden:
Hintergrundinfo: Die Käufe haben dort stattgefunden wo die eingelieferten jetzt auch lagern (nach Depotwechsel).
Was hier auffällt ist, dass bei beim VERKAUF der Reihe nach vorgegangen wird (=FiFo). Bei der UMBUCHUNG sieht man, dass zuerst die Käufe bevorzugt werden, und danach bei der ersten Einlieferung ein Teil abgezogen wird.
Aber es scheint lt. Screenshots noch ein Fehler vorzuliegen.
Screenshot 1: sämtliche Buchungen ergeben einen Betsand von 390,9889 Stück.
Screenshot 2: Buchungen ergeben einen Bestand von 370,9889 Stück (=minus 20 Stück).
Screenshot 3: Buchungen ergeben einen Bestand von 378,3709 Stück (=minus 12,618 Stück).
Wo sind die 7,382 Stück Differenz?
Fehlen bei den Screenshots Buchungen?
Ja das bitte ich zu entschuldigen, es gibt noch deutlich mehr Buchungen wollte das aber für eine bessere Übersicht begrenzen und hab nur Screenshots bis zum 19.4.22 gemacht. Bei der Umbuchung werden auch noch Käufe die danach stattfanden umgebucht, es sind insgesamt die 20.
Um den Sachverhalt zu zeigen werden die nicht dazu gebraucht.
Generell funktioniert die Umbuchung. Was nicht klappt, sind mehrere Buchungen über die gleichen Depots wie auch das Beispiel von @ProgFriese zeigt.
Ich gehe davon aus, dass das entweder bisher “übersehen” wurde, oder der Anwendungsfall so selten vorkommt, dass eine aufwendige “Korrektur” in keinem Verhältnis steht.
Am Ende muss man sich vor Augen halten, dass es bei einer solchen Sortierorgie nicht um Performance Tracking handelt!
Ich partizipiere fleißig an Depotübertragungsprämienaktionen und habe daher im Laufe der Jahre ziemlich viele Depotüberträge durchgeführt. Würde das FIFO Prinzip auch bei Depotüberträgen korrekt berücksichtigt werden, könnte ich mit PP tracken, ob die Anschaffungsdaten bei den Depotüberträgen von der abgebenden Bank korrekt übertragen wurden.
Konkret wurden bei mir fehlerhafte Daten von der Baader Bank übertragen und auch in einem comdirect-Depot stimmt etwas nicht. Ein korrektes Tracking wäre hier für mich eine riesige Hilfe.
Offenbar zeigt PP für jedes aktuell genutzte Depot einen Trade an. Wähle ich einen Trade aus und im Kontextmenü dann Umbuchung, wird mir das entsprechende Depot als Default Wert für das Ausgangsdepot angezeigt.
Hilfreich wäre es für meine Zwecke, in der Depotübersicht die jeweiligen Anschaffungsdaten für die dort aktuell verwahrten Wertpapiere anzeigen zu können.
Nur so als Gedankenspiel: In PP musst du nicht zwangsläufig jedes in der Realität existierende Depot separat abbilden. Du könntest auch alles in einem einzigen PP-Depot abbilden. Wenn du jetzt in der Realität das Wertpapier von Depot A nach Depot B überträgst, könntest du einfach bei dem betroffenen Wertpapier eine entsprechende Notiz einfügen. Wenn das eine in PP existierende Depot noch weiter aufgeschlüsselt werden soll, könntest du für die Wertpapiere noch zusätzliche Filter anlegen und könntest mit diesen Filtern eine Übersicht der einzelnen in Realität existierenden Depots erhalten. Wenn du dann ein Realität ein Wertpapier überträgst, muss nur die Zuordnung für den Filter angepasst werden (Drag & Drop).
Das manuelle Tracken ist sehr zeitaufwändig und auch fehleranfällig. Bis 2019 habe ich hierfür eine Excel-Tabelle geführt, dies aber zwischenzeitlich aufgrund des Aufwandes aufgegeben.
Mein Depotbestand für eine Aktie setzt sich aus insgesamt 12 im Laufe der Zeit getätigten Käufen zusammen die derzeit in 11 verschiedenen Depots wild gemischt liegen. Es ist sehr mühsam, jeweils genau nachzuhalten, welche Aktien von welche Käufen nach dem FIFO-Prinzip jeweils übertragen werden.
Zu meiner großen Freude habe ich nun entdeckt, das PP die Informationen - abgesehen vom Bug - grundsätzlich automatisiert verwaltet. Jeder offene Trade enthält die Informationen zu denen in einem Depot liegenden Aktien. Was fehlt: bei den Trades wird nicht das zugehörige Depot angezeigt. Die Information ist offensichtlich vorhanden, da man das zu einem Trade zugehörige Depot ermitteln kann, indem man zu einem Trade z. B. Kauf im Kontextmenü selektiert. Dann wird das Depot als Default-Depot für den Kauf angezeigt.
In der Depotansicht könnte man die zu einer Position gehörigen Anschaffungsdaten anzeigen, in dem man die Daten des zugehörigen offenen Trades heranzieht.
Vielen Dank für Deine Antwort. Sorry, ich hatte tatsächlich versäumt, die Spalte einzublenden.
Ich kann mit der Nicht-Anzeige bei der Depot-Ansicht gut leben.
Da ich nicht trade, sondern Langfristanleger bin, bin ich allerdings nicht auf die Idee gekommen, die Informationen über die Anschaffungsdaten zu meinem Depotbestand unter Trades zu suchen, und habe diese dort nur zufällig entdeckt. Vermutlich gab es die Funktionalität auch noch nicht, als ich mir die PP-Funktionalität systematisch komplett angesehen habe.
Bleibt nur noch der Fix des in diesem Thread beschriebenen Bugs offen ;-).
Hallo,
ich bin auf das selbe Problem gestoßen, FIFO wird nicht richtig berücksichtigt bei mehreren Depotübertragungen.
Ich darf einen Teil meiner Anlagen verkaufen und habe mich entschieden dies über HIFO (Highest In First Out) zu machen.
HIFO bedeutet hier beim Verkauf die zu Bezahlende Steuer zu minimieren, in dem man die Anteile der Anlage mit am wenigsten Gewinn verkauft.
Zusätzlich musste ich kurz vorher mein Onvista Depot umziehen (wegen deren Geschäftsaufgabe).
Vereinfacht tritt das Problem bei Anlagen die durch den Prozess gegangen sind:
100% Depotübertrag (Onvista auf Depot B)
Umbuchungen mehrere Trancen einer Anlage im HIFO Prinzip mit der Abfolge:
Depot B Übertrag 60% Anteile (niedriger Einstandskurs) an Unterdepot B.1
Depot B Übertrag 10% Anteile (hoher Einstandskurs) an Depot C (zweiter Broker)
Depot B Übertrag 15% Anteile (niedriger Einstandskurs) an Unterdepot B.1
Depot B Übertrag 15% Anteile (hoher Einstandskurs) an Depot C (zweiter Broker)
Depot C Anteile (hoher Einstandskurs) sollen verkauft werden, Unterdepot B.1 soll behalten werden (niedriger Einstandskurs).
Nach dem Vorgehen sind bei Depot C unter Trades “i” die Buchungen nicht korrekt nach FIFO übertragen worden. Es wird sogar die älteste Buchung mit 131 St. in mehrer kleinere Buchungen aufgeteilt und auf die Depots B.1 + C verteilt.
Ich hatte den Workaround auch probiert und im Schritt “- Depot B Übertrag 15% Anteile (niedriger Einstandskurs) an Unterdepot B.1” da Unterdepot durch ein Depot D ersetzt. Gleiches Problem, keine Besserung.
Erst als mit dem Schritt “1. 100% Depotübertrag (Onvista auf Depot B)” herumgespielt habe hat sich Besserung gezeigt. Ich musste alle Käufe im Onvista Depot in Depot B Importieren und die Umbuchung raus nehmen, dann wurden die FIFO Daten nach den Schritte 2 richtig angezeigt.
Das bringt natürlich das Problem, dass die Performance / Dividenden etc. nicht mehr separat für Depot Onvista und Depot B ausgewertet werden können.
Ich denke die HIFO Strategie und Depotumbuchungen werden häufiger eingesetzt und hin und wieder läuft jemand in das gleiche Problem.
Ich hoffe es wird an einer Lösung gearbeitet.
Ich bin großer Fan von PP und nutze es sehr gerne.
Although I don’t speak German, I used Google Translate & I believe the issue being addressed here relates to how we can account for sales as HIFO rather than FIFO, which is something I also really need. Haven’t been able to figure out a workaround that works.
…Actually, I stand corrected - I read the translation more carefully & this seems not to be related to HIFO sales but to an ordering bug with transfers…which is actually now also affecting me (I was linked here from this thread).
I’m trying to use PP to track crypto transfers & sales, which must be FIFO. Consider these operations:
Buy 1 unit on a crypto exchange, call it lot E1
Buy 1 unit in a wallet, W
Buy another on the same exchange, call it lot E2
Transfer everything from the exchange to the wallet (2 units)
Some time later, transfer 1 unit from the wallet back to the exchange. I would expect that it would pull E1 here as it’s oldest.
Sell 1 on the exchange. I would expect it to be E1.
However, it sold W. This does seem like a pretty impactful bug, as in this case it would lead to incorrect sales order for tax reporting purposes.
Curious, has this been reported as a bug on Github yet? Maybe it would get more visibility from the developer there?
Edit: For a little more context, I’ve been using PP for tracking crypto sales for tax reporting purposes. It’s worked great for the past several years, where I’ve just had one “Crypto” account (regardless of the actual number of wallets/exchanges) - so-called “Universal Accounting.” Starting 1/1/2025 though, you’re no longer allowed to do that in the US (see: here). Instead, you must do FIFO wallet-by-wallet. So I’ve created a separate account for each exchange or wallet, & transfer the assets in PP just as they move in reality. However, this bug means seems to mean that won’t work - it gets out of the correct FIFO order. Pretty big issue honestly - I have no idea how I’ll be able to track things & comply going forward.
I’m trying to understand more concretely when this bug arises (I’ve done my best to make sense of the thread, but it’s tricky with Google Translate - I think it translates “transfer” as “booking,” and “rebooking” means multiple subsequent transfers (maybe?)). Specifically, when can I be confident that it will properly respect the FIFO order, & when might it not? I think it’s the following:
Anytime you transfer shares more than 1 time, the FIFO order of transfer #2 & later may be incorrect. So i.e. Buy in account A → Transfer to account B (correct order) → Now if you transfer to any other account, that transfer may be out of FIFO order
(I saw some comments that made me think it’s only when you transfer shares from Account A to Account B and then back to Account A, the second transfer will be out of FIFO order. But I tested A->B->C, & the transfer B->C had the bug, so I don’t think this is the case.)
If anyone can solidify this for me I’d appreciate it - maybe @Jo92 or @Avendo or @Sn1kk3r5 seemed to understand it clearly.
With crypto, moving assets between accounts is very common. At minimum I’d like to understand when PP won’t track this correctly, & then to figure out what my options are as this bug is making my accounting extremely challenging, since its bookeeping no longer matches what’s required to be reported for tax purposes.
Clarifications & thoughts would be greatly appreciated.
Edit: It would also be good to understand how it actually chooses the lots (i.e. it’s not in FIFO order, what is the order used?)
Edit 2: If any of the other affected users would be willing to pitch in, how would we feel about starting a bounty to try to get this fixed quickly?
