Schau mal, ob du irgendwo (Stammdaten/Alle Buchungen) eine Buchung mit Datum 21. 12. 22 statt 21. 12. 2022 hast o.ä.
1 Like
@chirlu tatsächlich habe ich das als erstes geprüft und nein.
Das wäre mir auch in der Excel Berechnung aufgefallen. Wenn die gleiche Logik in PP für den IZF angewendet wird, wie in Excel und ich mit Strg + A alle Werte des Fonds kopiert habe, kann das m. E. keine Erklärung sein.
Ok, ich kann das Phänomen mit den hohen IZF nachvollziehen.
Bei 20 Jahren oder 40 Jahren ist das okay, bei 44 Jahren laufe ich auch in ein Problem. Das muss ich debuggen. Etwas komisch, weil die Datenreihe sich an sich nicht ändern weil der erste Kauf 2009 ist 
Ich meinte nicht nur den Fonds, sondern tatsächlich alle Buchungen.
So oder so wird es kaum reproduzierbar sein ohne die Originaldatei.
@chirlu klar. Das habe ich geprüft, nicht dass es einen unerwarteten Querbeschuss gibt.
@AndreasB kann das Phänomen aber ja auch nachvollziehen. Deshalb vermute ich da schon etwas komisches in PP. Vielleicht doch noch ein Jahr 2000 Problem 
Just FYI - hier die Testdatei die ich aus Deinen Daten generiert habe.
deka-beispiel.xml (59,2 KB)
2 Likes
Es liegt wohl daran, daß der Barwert auf den ersten Tag des Berichtszeitraums berechnet wird:
Vermutlich kommt es da irgendwo (mit diesen Daten) zu einem Unterlauf, der dann letztlich bewirkt, daß die Newton-Suche scheitert.
Wenn man stattdessen den Barwert zum Ende des Berichtszeitraums nimmt (also meistens zu heute), vermeidet man, daß sich allein durch den prinzipiell unbegrenzten „Leerraum“ am Anfang etwas am Ergebnis ändert. Außerdem werden die Zahlen dadurch größer, nicht kleiner, was meistens sicherer ist; und man kann multiplizieren statt dividieren, ebenfalls meistens sicherer.
Das wären zwei kleine Änderungen in NPVFunction.java.
2 Likes
Das könnte ich mal ausprobieren.
Bisher habe ich einfach den “Leerraum” entfernt. Es macht eigentlich keinen Sinn die IZF Berechnung mit dem Start den Berichtszeitraum zu beginnen, wenn für das Wertpapier da keine Daten existieren. Was meinst du? Oder sieht Du da Probleme bei anderen Datensets?
Der Fehler ist mir heute das erste mal aufgefallen. Vlt. Zufall, vlt. ist er auch erst in einer der letzten Versionen entstanden…
Ergänzung:
Hilft jetzt nicht bei der Problemlösung, aber diese Zahl wollte ich euch nicht vorenthalten.
Weitere Ergänzung:
Bei mir ist das der Berichtszeitraum “1 Jahr”, tritt also nicht nur bei langen Zeiträumen auf.
Mit Version 0.60.1 ist der Fix oben drin.
@Mondorbit das dürfte ein anderes Problem sein. Im Thread oben war der IZF ja okay bei 10 Jahren, aber bei 20 Jahren Berichtszeitraum nicht mehr. Aber um mehr zu sagen, braucht es Daten (meist sind es extrem kurze Zeiträume oder falsche Buchungen).
@AndreasB Ich habe heute das Update eingespielt und stelle fest, dass das von mir geschilderte Problem behoben ist.
Besten Dank für die schnelle Analyse und prompte Behebung!
Dein Riecher täuscht dich nicht. Es liegt tatsächlich an einem kurzen Zeitraum. Zumal ich das Wertpapier zum Einstandspreis ausgeliefert habe, während der aktuelle Kurs deutlich niedriger war.
Scheinbar ist durch den Fix ein anderer Fehler entstanden. Und zwar wird der IZF nicht aktualisiert, wenn im gewählten Berichtszeitraum keine Wertpapiere gehalten werden.
Was meinst du mit „nicht aktualisiert“?
Berichtszeitraum ohne Wertpapiere → Performance aufrufen → Widget leer, statt 0% → Berichtszeitraum wählen mit Wertpapieren → IZF wird richtig angeigt → Berichtszeitraum wählen ohne Wertpapiere → vorriger Wert bleibt stehen, statt 0%.
Hallo,
auch in meinem Portfolio gibt es eine Aktie (Biontech), für die ein irrer IZF ausgerechnet wird.
Ich habe mal alles Übrige gelöscht und eine ganz kleine XML-Datei mit ganz wenigen Kursen erzeugt.
Es ergeben sich 3 IZFs:
a) im Dashboard 31,41% IZF p.a. (2 oder mehr Jahre)
b) Berichte/Performance/Wertpapiere, Spalte IZF: 1.918.265%
c) Berichte/Performance/Trades, Spalte IZF: 1.417.740%
Kann das ein?
Ich denke, ein Entwickler kann relativ schnell nachvollziehen, wo/wie die IZF-Werte im Programm entstehen.
Dies also als Beispiel zur Problemfindung. Mein System: Windows 10, PP 0.60.1
Gruß
Test_IFZ.xml (25,4 KB)
1 Like
Das ist aber richtig so. Der Unterschied zwischen b und c liegt an den Steuern, die bei c abgezogen sind und bei b nicht; nicht ganz sicher, ob das so sinnvoll ist, aber ein Rechenfehler liegt nicht vor.
Also sind %-Werte von 1 oder 2 Millionen richtig??
Ja, die sind richtig. Ein Gewinn von mehr als 50% in nur 17 Tagen ist einfach sehr viel.