New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance eines Wertpapieres wird nicht korrekt berechnet, wenn nachgekauft wird #615

Closed
ghost opened this Issue Sep 1, 2016 · 20 comments

Comments

Projects
None yet
3 participants
@ghost

ghost commented Sep 1, 2016

Wird ein Wertpapier nachgekauft und ist der Kaufkurs höher als der aktuelle Kurs (Ausgeabeaufschlag), wird die Performance (TTWROR) abe diesem Zeitpunkt nicht mehr korrekt berechnet. Die Gesamtperformance des kompletten Portfolios ist für mich nachvollzeihbar.
Da jedoch nur dieses eine Wertpapier enthalten ist, müsst die Gesamtperformance und die des Wertpapieres nahezu gleich sein. Oder habe ich einen Denkfehler?
Anbei 2 Beispieldateien.

Test.zip

@buchen

This comment has been minimized.

Owner

buchen commented Sep 2, 2016

Ich werde mir die Datei anschauen.

Da jedoch nur dieses eine Wertpapier enthalten ist, müsst die Gesamtperformance und die des Wertpapieres nahezu gleich sein.

Wenn das Gesamtportfolio nur dieses Wertpapier enthält, dann sollte die Performance gleich sein.

Hast du noch ein Referenzkonto erfasst? Eine Cashposition auf dem Referenzkonto "dämpft" natürlich die Performance, da Cash um die 0 Prozent bringt.

Und natürlich will ich nicht ausschliessen dass es auch Bugs gibt 😉

@buchen buchen added this to the 2016 Q3 Short-List milestone Sep 2, 2016

@ghost

This comment has been minimized.

ghost commented Sep 2, 2016

Es gibt ein Referenzkonto, auf das jedoch 1 Tag vor dem Kauf die jeweilige Summe eingebucht wurde (Einlage) die zum Kauf verwendet wurde; Ansonsten befinden sich nur die Dividenden darauf.
Mich wundert, dass die Gesamtperformance besser ist als die des Wertpapiers. Die Gesamtperformance kann ich rechnerisch nachvollziehen und ist meiner Meinung nach richtig. Anbei ein Bild von Test02.xml.
test02-perf
Zum Test habe ich ein Wertpapier mit einer Kurssteigerung von 1% por Jahr kreiert. Am Jahresende wird die Dividende in Höhe der Wertsteigerung ausgezahlt und der Kurs fällt auf den Anfangswert (100,- €) zurück. Das ergibt eine Performance von 1% pro Jahr.
Das oben beschriebene Verhalten ist mir bein einem realen Immobilienfonds aufgefallen.

@buchen

This comment has been minimized.

Owner

buchen commented Sep 4, 2016

Hi @hendrikm78,

ich habe mir jetzt die Datei "Test02.xml" angeschaut --> also die Frage, warum sich die Performance von dem Gesamtportfolio und "Test 1%" unterscheiden.

Es ist das selbe Problem wie hier im Forum beschrieben: Aktuell wird die Performance eines Tages bereits investierten Kapital zugeordnet.

In Deinem Fall kaufst Du das Wertpapier zu 101:
bildschirmfoto 2016-09-04 um 10 55 29

Der Kurs am Ende des Tages ist aber drunter:
bildschirmfoto 2016-09-04 um 10 55 17

Dieser Verlust wird dem bisherigen Kapital zu geordnet.

In dem "Gesamtportfolio" tritt das nicht auf, weil bei der Betrachtung des Gesamtportfolios der Mittelzufluss ja schon einen Tag vorher auftritt. Wenn Du die Einzahlung auf den selben Tag legst, dann sind die Kurven (fast) identisch (ich denke die kleine Cashposition macht den Unterschied):

bildschirmfoto 2016-09-04 um 11 02 48

Ich habe vor diese Berechnung zu ändern, aber leider bin ich noch nicht dazugekommen. In der Literatur gibt es den midday-cashflow, aber auch hier bleiben noch Abweichungen. Ich überlege die Performance des Zukaufs separat zu rechnen und dann mit der Performance des restlichen Investments zu verrechnen. Ich bin noch nicht dazu gekommen. 😐

@buchen buchen removed the question label Sep 4, 2016

@ghost

This comment has been minimized.

ghost commented Sep 6, 2016

Hi @buchen,
alles klar, so etwas ähnliches habe ich mir schon fast gedacht. Wenn man mehrere Nachkäufe hat, so kann es passieren, dass die Performance <0% ist, der IZF jedoch >0% und Betragsmäßig auch ein Wertzuwachs festzustellen ist.
Wäre es nicht sinnvoller, wenn sich direkt ab dem Kauf die Performance auf die Summe des investierten Geldes und des Kaufbetrages bezieht?

@buchen

This comment has been minimized.

Owner

buchen commented Sep 13, 2016

Aus dem Wertpapier Forum:

Hast du denn mal in Erwägung gezogen, Mittelzuflüsse grundsätzlich am Tagesanfang und Mittelabflüsse am Tagesende anzuwenden? Das ist keine große Änderung der bestehenden Formel und die Performance eines Cashflows wird in beide Richtungen korrekt angewendet: Bei einem Kauf werden Kaufkosten und Kursunterschiede des Tages nach Mittelzufluss (auf den Bestand nach Kauf) angewendet. Bei einem Verkauf werden Verkaufskosten vor Mittelabfluss (auf den Bestand vor Verkauf) angewendet (Kursänderungen können nicht mehr stattfinden, wenn die Position geschlossen ist).

(Vt - Cut) / (Vs + CIt)

Vt = Bewertung am Zeitpunkt (Tag) t
Vs = Anfangsbewertung
CO = Cash flow out
CI = Cash flow in

@ghost

This comment has been minimized.

ghost commented Sep 13, 2016

Sieht gut aus.

@michaellass

This comment has been minimized.

michaellass commented Jan 18, 2017

(Vt - Cut) / (Vs + CIt)

Vt = Bewertung am Zeitpunkt (Tag) t
Vs = Anfangsbewertung
CO = Cash flow out
CI = Cash flow in

Das sah mir nach keiner großen Änderung aus, daher habe ich versucht, es zu implementieren (siehe verlinkter Commit). Allerdings hat das als Seiteneffekt, dass Einlagen nicht mehr performance-neutral sind.

Gibt es überhaupt eine Möglichkeit, dieses Problem zu beheben, ohne eine Reihe anderer zu schaffen?

@michaellass

This comment has been minimized.

michaellass commented Jan 25, 2017

Ich habe noch einen zweiten Versuch unternommen, das Problem anzugehen, indem nur Steuern und Gebühren in Relation zu den Einlagen des jeweiligen Tages berechnet werden und der Rest nach wie vor nur in Relation zum Gesamtwert des Vortages. Das löst Probleme mit einigen Testfällen, aber nicht mit allen.

An dieser Stelle steige ich ersteinmal aus, da ich unsicher bin, was genau hier ein gewünschtes Verhalten ist und ob ein paar der Tests entsprechend angepasst werden müssten. Auch was alles zu den Einlagen zählen sollte ist mir nicht klar (z.B. auch Steuerrückzahlungen?).

@imagine-ecommerce

This comment has been minimized.

imagine-ecommerce commented Jan 26, 2017

Hi @michaellass ,

die Formel aus dem Wertpapierforum stammt ursprünglich von mir. Vielleicht ist diese Erläuterung dazu hilfreich.

Zunächst hat die Variable COt (Copy und paste hat oben scheinbar daraus ein "Cut" gemacht) als "Cash flow out" ein negatives Vorzeichen, insofern ist die folgende Schreibweise eindeutiger:

(Vt + Abs(COt)) / (Vs + CIt)

V = Bewertung der Position zu einem Zeitpunkt
s = Start (Zeitpunkt vor dem Mittelfluss, d.h. hier am Ende des Vortags)
t = Messpunkt (Zeitpunkt nach Mittelfluss und Gebühren), d.h. jetzt oder am Ende des Tages des Mittelflusses- was immer davon früher ist)
CO = Mittelabfluss ohne Gebühren und sonstige damit verbundenen Kosten
CI = Mittelzufluss ohne Gebühren und sonstige damit verbundenen Kosten

Vt ist immer die Bewertung der Position nach Gebühren und Mittelflüssen.

Korrekt angewendet ist eine Einlage nach dieser Formel performanceneutral, wie das folgende Beispiel zeigt:

Eine Position enthält 1 Stück zum Preis von 10,00 Euro (Vs = 10,00 Euro). Nun kaufen wir 10 Stück zum Preis von 10,00 Euro (CIt = 100,00 Euro). Bleibt der Kurs gleich, sollte die Rechnung also performanceneutral sein:

(110,00) / (10,00 + 100,00) * 100 - 100 = 0%

Perfekt! Jetzt simulieren wir zusätzliche eine Kursänderung von -10% zum Kaufzeitpunkt:

(99,00) / (10,00 + 90,00) * 100 - 100 = -1%

Die Performance sinkt, allerdings nicht um -10% sondern nur marginal, da wir die 10 Stück erst nach dem Kursrutsch gekauft haben. Das ist der große Unterschied zur bisherigen Implementierung!

Nehmen wir alternativ einmal an, dass der Kurs gleich bleibt und Kosten von 10,00 Euro für den Kauf von 10 Stück angefallen wären:

(100) / (10,00 + 100,00) * 100 - 100 = -9,1%

Wir haben einen Vermögenswert von 10,00 Euro, tätigen dann einen Kauf mit sofortigem Verlust von 10% durch Kaufkosten und die Gesamtperformance sinkt um -9,1%, weil der Verlust nur auf das Tagesgeschäft angewendet wird.

Nebenbei: Persönliche Steuern wie die Kapitalertragssteuer haben meiner Meinung nach in der Performanceberechnung nichts zu suchen, weil sie die Vergleichbarkeit der Messung unmöglich machen.

@buchen

This comment has been minimized.

Owner

buchen commented Jan 26, 2017

@imagine-ecommerce - Danke für das ausführliche vorrechnen.

@michaellass - ich hatte auch schon mal angefangen, bin aber auch an existierenden Testfällen hängen geblieben 😄 Aktuell sammele ich die Mittelzuflüsse/-abflüsse in einer Variable. In einem ersten Schritt würde ich das erst mal aufteilen in "inbound" und "oubound cash flows". Wenn Du das hast, check pushe den Code doch gerne noch mal hoch. Die weiteren Testfälle kann ich mir anschauen.

@michaellass

This comment has been minimized.

michaellass commented Feb 4, 2017

Ich bin bisher noch nicht zu einem weiteren Anlauf gekommen, habe es aber noch auf dem Schirm.

Bei der Gelegenheit wäre die Frage, ob man das Einbeziehen von Gebühren und/oder Steuern in die Performance konfigurierbar machen möchte. @imagine-ecommerce hat ja die persönlichen Steuern schon angesprochen und ich meine mich zu erinnern, dass auch schon diskutiert wurde, ob die Gebühren mit einfließen sollen. @buchen, was meinst du?

Persönlich fände ich das gar nicht schlecht. So könnte man gut sehen, wie viel der persönlichen Performance durch Gebühren aufgefressen wird.

@buchen

This comment has been minimized.

Owner

buchen commented Feb 5, 2017

Bei der Gelegenheit wäre die Frage, ob man das Einbeziehen von Gebühren und/oder Steuern in die Performance konfigurierbar machen möchte.

Aktuell wird die Performance unter Einbeziehung von Gebühren und Steuern berechnet. Ich würde auch in einem ersten Schritt die Rechnung erst mal so ändern, dass Zu/Abflüsse besser verrechnet werden.

Ein zweiter Schritt (separater Change) ist dann die Konfiguration. Vermutlich würde man in den Auswahldialog für die Datenreihen noch mehr einfügen (quasi verdoppeln).

@ghost

This comment has been minimized.

ghost commented Apr 27, 2017

Die Berechnung von @imagine-ecommerce finde ich richtig und nachvollziehbar.

In der aktuellen Version ist es so, dass Gebühren und Dividenden auf die Performance des einzelnen Wertpapiers angerechnet werden.
Die Steuern werden nicht bei Betrachtung eines einzelnen WPs in der Performance berücksichtigt. Dies würde ich auch so belassen, da Steuern sehr individuell sind und die Performance eines WP verfälschen, z. B. könnte es vorkommen das Gewinne aus Verkäufen zu Anfang des Jahres noch steuerfrei sind (Freibetrag), am Ende des Jahres jedoch besteuert werden. Somit wäre ein Vergleich der Performance von einzelnen WPs deutlich erschwert.
Bei Auswertung des Deopts, Depot+Konto oder des Gesamtportfolios werden die Steuern ebenfalls berücksichtigt.

Ein- und Auslieferungen sind Performance-neutral, das ist soweit richtig.

Leider bin ich nicht fit in github, daher meine Änderungen am aktuellen Snapshot (0.26.6) hier als diff-Files.
Performance-Issue-01_HMR.zip

@buchen

This comment has been minimized.

Owner

buchen commented May 13, 2017

Ich habe basierend auf dem Change von @hendrikm78 PP jetzt angepasst.

Das aufwändigste war die Performance Berechnung von Kategorien. Vorher habe ich der Einfachheit halber alle Umbuchungen, Käufe, etc. in Einlagen / Auslieferungen umgewandelt. Die transferals haben sich ja wieder aufgehoben. Da jetzt inbound und outbound transferals separat betrachtet werden, hatte das plötzlich einen Performanceeffekt.

Ich habe eine Testversion hier hochgeladen - @hendrikm78 @michaellass @imagine-ecommerce - Zeit zu testen?
Win 64bit | Win 32bit | macOS

@michaellass

This comment has been minimized.

michaellass commented May 13, 2017

Ich habe eben den aktuellen Stand des feature_perf_calculation Branches kurz angetestet (bin aktuell unter Linux). Das sieht sehr gut aus!

Mir ist aufgefallen, dass in einem Portfolio, wo ich mit einem Sparplan einem einzelnen Wertpapier folge, die Performance nun nicht mehr genau dem Wertpapier entspricht. Aber ich schätze, das ist zu erwarten, wie der hinzugefügte Kommentar in testThatPerformanceOfAnInvestmentIntoAnIndexIsIdenticalToIndex() sagt:

performance is only identical if the capital invested
additionally has the identical performance on its first day -->
use the closing quote of the previous day

Das hatte mich damals bei meinen Versuchen etwas verunsichert.

@buchen

This comment has been minimized.

Owner

buchen commented May 13, 2017

Mir ist aufgefallen, dass in einem Portfolio, wo ich mit einem Sparplan einem einzelnen Wertpapier folge, die Performance nun nicht mehr genau dem Wertpapier entspricht.

Bei meinem echte Portfolio unterscheiden sich die Performance Kennzahlen für das Gesamtportfolio oder grosse Kategorien (Asset Allocation) nur in der zweiten Nachkommastellen. Bei einzelnen Wertpapier sieht das teilweise anders aus. Da hat sich sich auch einmal um 0.5 geändert.

@michaellass

This comment has been minimized.

michaellass commented May 13, 2017

Ja, das deckt sich zahlenmäßig gut mit meinen Beobachtungen. Der Effekt ist sehr klein und gleicht sich vermutlich über die Zeit und über mehrere Wertpapiere hinweg aus. Insgesamt finde ich, wird die Performance mit dieser Änderung deutlich besser abgebildet - insbesondere eben in der Anfangszeit eines sich aufbauenden Portfolios, wo dieser Bug stark zum Tragen kam. 👍

@ghost

This comment has been minimized.

ghost commented May 21, 2017

Ich habe die Testversion ausprobiert. So wie ich das sehe, sind die Ergebnisse jetzt wie erwartet.
Die Unterschiede im TTWROR entstehen dadurch, dass hier zum einen die Einlagen in das Gesamtportfolio und ein vorhandener Spread/Ausgebeaufschlag korrekt berücksichtigt werden.

  • Bis jetzt war es so, dass Einlagen immer einen Tag vor dem Kauf des WPs gebucht werden mussten, damit diese richtig erfasst wurden.
  • Bei Kauf eines WP wird jetzt der Verlust durch den Spread/Ausgabeaufschlag auf die Summe aus Depowert vor Kauf und den Kaufpreis bezogen. Der Differenz zwischen den beiden Programmversionen ist um so größer, je höher der Spread/Ausgabeaufschlag ist.
    Hier mal ein Extrembeispiel:
    Demo_Immo_Global.zip
    Die Wertentwicklung in € ist positiv, jedoch wurde ein negatives TTWROR errechnet (alte Version), richtig müsste es aber positiv sein (Testversion).
    Ich denke in diesem Zusammenhang sollte auch #61 gelöst sein.

@ghost ghost closed this May 21, 2017

@ghost ghost reopened this May 21, 2017

@buchen

This comment has been minimized.

Owner

buchen commented May 21, 2017

Mit der neuen Version sind die beiden absolut identisch.

bildschirmfoto 2017-05-21 um 16 01 38

im Gegensatz zu (alter Version):

bildschirmfoto 2017-05-21 um 16 01 48

So ganz gesund sieht der Graph trotzdem noch nicht aus.

Wenn alles gut geht, werde ich gleich die neue Version bauen und veröffentlichen.

@ghost

This comment has been minimized.

ghost commented May 21, 2017

Die Peaks kommen daher, das ich den Eingang der Dividenden einen Tag früher als in der Realität gebucht habe, zu diesem Zeitpunkt hat der Kurs des WP den entsprechenden Rückgang noch nicht vollzogen. Dies erfolgt einen Tag später.
Ich habe gerade mal testweise für 2016 das Datum korrigiert, dann verschwindet auch der Peak, das ist kein Programmfehler.
Ab Mitte 2016 hat sich die Quelle für die Kurse geändert. Vorher waren es die Werte von der Fondsgesellschaft, jetzt sind es Werte von Onvista von einem Börsenplatz. Dies sollte den Unterschied ab diesem Zeitpunkt erklären.

@buchen buchen closed this May 21, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment