portfolio-performance
Gelegentlich falsches Vorzeichen bei Gewinn/Verlust
Describe the bug In "Zahlungen" und exportierten Trades werden falsche Ergebnisse angezeigt. Bei Blick auf die einzelnen Trades enthalten einige Trades das falsche Vorzeichen. (z. B. Einstiegspreis 32.002,00 Ausstiegspreis 30.598,00 Gewinn/Verlust 1.404,00 Bruttoprofit 1.400,00) In der Version von vor einem Jahr wurde noch richtig gerechnet. ( Einstiegspreis 32002,00 Ausstiegspreis 30598,00 Gewinn/Verlust -1404,00 Bruttoprofit -1400,00 ) Dadurch wird das Monats-/Quartals-/Jahresergebnis verfälscht. Den Bug eröffne ich so spät, da ich dachte, dass so ein offensichtliches Problem sofort auffallen muss und in kürzester Zeit behoben wird. Leider ist die Version, bei der ich den Fehler erstmalig feststellte, auch schon über vier Monate her.
To Reproduce Steps to reproduce the behavior: Don't know. Zurücksetzen auf alte Version?
Expected behavior Richtige Addition positiver und negativer Beträge.
Screenshots
Desktop (please complete the following information):
- OS: Windows 10
- PP: Version: 0.79.1 (August 2025)
Ich nehme an du nutzt Excel bzw. ein äquivalents Tool.
Da diese Tools runden und formatieren, müßten wir die csv sehen. Am besten ein Screenshot von PP vor dem Export, samt Buchung und dann die CSV dazu.
Das hat nichts mit dem Export oder Excel zu tun. Es ist ein Rechenfehler in PP.
In PP kann ich nur leider den alten Stand, wo noch richtig gerechnet wurde, nicht anzeigen lassen.
Aktuell sieht aber direkt in PP, dass offensichtlich falsch gerechnet wird:
So können wir das leider nicht nachvollziehen. Es können einige Dinge reinspielen Wir brauchen entweder Screenshots, oder ein minimal Beispiel als xlm.
In deinem Screenshots kann niemand sehen, wo du gerade schaust, wie die Filter und Zeiträume stehen und wie die Buchung dazu aussieht.
Mit dem XML sollte es jetzt nachvollziehbar sein. In "Zahlungen" und "Trades" werden falsche Werte berechnet. Der Saldo im Konto ist korrekt
.
Danke! Ich hab deinen Fehler gefunden.
Du hast 4 Buchungen (05.04)(Je 2 Kauf und 2 Verkauf auf jeweils 00:00 gelegt) Damit kann PP nicht umgehen. Wenn du die Käufe auf eine frühere Zeit als die Verkäufe legst dann passt es auch wieder.
O.K., danke für den Workaround. Mir ging es aber eigentlich darum, dass irgendwann im letzten Dreivierteljahr dieser Fehler eingebaut wurde, da es vorher korrekt gerechnet hatte. Wenn der Ausstiegskurs unter dem Einstiegskurs liegt, darf in keinem Fall ein Gewinn ausgewiesen und die Ordergebühren auch noch hinzuaddiert werden. Bei der Zahl von meinen Buchungen finde ich es unzumutbar, jedesmal manuell auch noch die Uhrzeit zu erfassen -- für das Datum wird ja ein Default vorausgewählt, aber für die Uhrzeit ist der Default 0:00.
Ein Workaround ist es nicht wirklich.
Ja es wurde einige Dinge angepasst, richtig. Das hat aber nur entfernt etwas mit deinem Problem zu tun.
Dein Problem wird verursacht, weil du 4 Buchungen an einem Tag erstellst. Wie soll PP die auseinander halten? Das wäre genau das gleiche als würde ich dir 4 Ausdrucke nur mit Datum ohne Uhrzeit vorlegen und sagen, sortiert mal bitte. Ja der Kauf muss vor dem Verkauf passieren, und dann?
Entschuldige die Wortwahl, aber:
Bei der Zahl von meinen Buchungen finde ich es unzumutbar,
- Es gibt eine auto. Import Funktion
- PP ist weniger für Trading als B&H gedacht
- Niemand zwingt dich etwas für dich unzumutbares auf dich zu nehmen
Du hast es hier mit OpenSource zu tun, die von Menschen in ihrer Freizeit betreut, gepflegt und gewartet wird.
Die Zeit automatisch zu übernehmen ist grundsätzlich keine schlechte Idee, verhindert aber auch das Problem nicht wenn man in der gleichen Minute eine weitere Buchung anlegt.
Ich frage mich bei der Diskussion des Problems, wie es wohl in einer Buchhaltungssoftware gelöst wird. Ein klassischer analoger Buchhalter würden den Stapel mit Ausdrucken mangels anderer Zeitinformationen wohl der Reihenfolge auf dem Stapel nach abarbeiten. FIFO.
Neben hh:mm könnte eine Datenbank noch eine Ganzzahl für die Reihenfolge der Eingabe (ggf. umsortierbar) abspeichern. Als Hack wäre das auch über Sekunden bzw. Millisekunden machbar, sodass der Code zum Sortieren nicht einmal angepasst werden müsste.
Ein klassischer analoger Buchhalter würden den Stapel mit Ausdrucken mangels anderer Zeitinformationen wohl der Reihenfolge auf dem Stapel nach abarbeiten.
Ich denke er würde nachfragen, bevor es ggf. komplett falsch wird. Wie unterschiedlich die Ergebnisse sein können siehst du in meinem Screenshot.
eine Datenbank
Die gibt es nicht und würde eine riesige Änderung nach sich ziehen. Es gibt ein Sideproject, was sich mit dem Import aus dem XML in eine Datenbank beschäftigt.
Man darf nicht vergessen wie alt der Kern von PP ist, und was die Aufgabenstellung seiner Zeit war. Und wenn man diesen Maßstab nimmt, macht PP seine Sache nicht perfekt, aber extrem gut.
Der Fehler kann nicht in der fehlenden zeitlichen Reihefolge der Buchungen liegen, sondern muss woanders zu suchen sein. Aufgrund der Kommutativität der Addition darf die Reihenfolge keinen Unterschied machen. Tatsächlich wurden die Buchungen zu den korrekten Trades zugeordnet, was darauf hindeutet, dass intern der Erfassungsreihenfolge gefolgt wird. Auch sind An- und Verkauf als solche klar unterschieden.
Nur wird im einen Fall als Summe korrekterweise
(1) Verkaufspreis - Ankaufspreis - Gebühren
gerechnet. Im Fehlerfall ist dagegen das ausgewiesene Tradeergebnis
(2) Ankaufspreis - Verkaufspreis + Gebühren = - (Verkaufspreis - Ankaufspreis - Gebühren).
Dies ist mir nur bei Verlusttrades aufgefallen. Ich kann nicht ausschließen, dass ich nur dort beim Erfassen in der Reihenfolge beim An- und Verkauf durcheinandergekommen bin. In der Tradeübersicht werden im Fehlerfall An- und Verkauf in der Transaktionszusammenfassung des Trades umgekehrt ausgewiesen:
im Ggs. zu
Würde also auch hier nach o. g. Formel (1) gerechnet, wäre das Ergebnis ebenfalls korrekt. Wenn jedoch die Reihenfolge der Transaktionen in der oben gezeigten Tabelle zugrundegelegt wird, muss es zu dem Fehler kommen.
Sollte sich der Fehler nicht beheben lassen, bestünde für mich das Ärgerliche darin, dass ich zur Umgehung, z. T. Jahre nachdem die Transaktionen durchgeführt wurden, ca. 2800 Buchungen manuell anpassen müsste. Da wäre eine Datenbank schon hilfreich. 😉
Auf jeden Fall möchte ich an dieser Stelle auch mal Danke sagen für ein einmaliges Programm, das seinesgleichen sucht!