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:
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!