Import von Abrechnungen hinterlässt Fehlbestand auf Depot

PP errechnet ihn nach obiger Formel, daher kannst Du ihn nicht korrigieren.

Ich kann Dir nicht folgen. Stückzahl und Gesamtbetrag stimmen. Damit stimmt der Bestand auf Depot und Konto und die Performancerechnung auch. Da sollte keine Korrekturbuchung nötig sein.

2 Like

Kann es sein, dass Du hier etwas übergenau bist? :grimacing:
Wir reden von der vierten Nachkomma-Stelle, sowohl Stückzahl als auch Endbetrag der Abrechnung sind korrekt in PP übernommen worden … Das heißt, es gibt weder Fehlbestand noch Fehlbetrag :slightly_smiling_face:

Grüße,
Andreas

PS: @Thomas war schneller :sunglasses:

2 Like

@Thomas @digitus
Dann habe ich mich vielleicht etwas unklar ausgedrückt. Ob 3 oder 4 Nachkommastellen, ist mir eigentlich relativ egal, vermutlich wären mir auch 2 lange gut genug. :upside_down_face:

Was ich bzgl. der Importfunktion meine ist, dass man dann ja nicht durchweg mit dieser arbeiten kann. Es nützt mir nichts meine Wertpapierabrechnungen zu importieren, wenn nach Kauf und späterem Verkauf von Positionen sich Differenzen durch Rundungsfehler ergeben. So entstehen ja immer wieder Fehlbeträge oder Restbestände die in irgendeiner Art korrigiert werden müssen. :face_with_monocle:Da kann ich dann auch alles direkt händisch eingeben. Ich denke allerdings nicht, dass dies die Intention bei Implementierung der Importfunktion war oder?

Mein Wunsch wäre, wenn ich eine Position in, sagen wir, 10 Tranchen kaufe und später in einem Rutsch komplett verkaufe und ich alle Käufe und Verkäufe per Import erfasse, dass hier keine Restposten bleiben. Das hat bei mir nicht funktioniert. :man_shrugging:

Das oben angeführte Beispiel kann für das beschriebene Verhalten (Rest-/Fehlbestände) nicht die Ursache sein, denn sowohl die Stückzahl als der Gesamtbetrag wurden richtig erkannt.
Bei welcher Buchung wurde denn die Stückzahl oder der Gesamtbetrag falsch eingelesen?

Die Position wurde über 23 Tranchen aufgebaut und dann über einen Verkauf komplett aufgelöst.

Seitdem schleppe in eine Restbetrag mit mir rum:

Der Gesamtbetrag und die Stückzahl stimmt bei allen Zugängen, allerdings der Kurs nicht. Denn diesen berechnet PP ja aus dem gelieferten aber bereits auf 2 Nachkommastellen gerundeten Gesamtbetrag.

Denn 4,2928 Stk. x 232,9500 € = 1000,01 (Abrechnung)

aber 1000,01 € / 4,2928 Stk. = 232,9505 € (PP)

denn die 1000,01 € aus der Wertpapierabrechnung sind eben eigentlich 1000,00776 €.

So summieren sich eben ggf. Buchung für Buchung Fehlbeträge auf weil mit unterschiedlichen Nachkommastellen gerechnet wird. Auf 23 Buchungen waren es in diesem Fall 10 x 0,01 €.

Frage wieso können die Werte aus der Abrechnung nicht einfach 1:1 ohne Berechnung durch PP übernommen werden oder wieso übernimmt PP nicht zumindest Stk. und Kurs 1:1 und rechnet dann wie es Broker/Bank auch machen?

Wir drehen uns hier im Kreis.

Wenn alle Stückzahlen richtig sind, dann hat PP entweder einen Fehler beim Addieren und Subtrahieren oder eine der Buchungen stimmt in der Stückzahl nicht. Aber am Kurs kann das nicht liegen. Der hat keinen Einfluss auf den Bestand.

Der Tooltip über dem Bestand von 0 zeigt Dir den ungerundeten Wert. Vermutlich 0,0004. Und das ist genau die Summe aller Deiner Buchungen. Vermutlich stimmt einer Deiner Buchungen nicht.

Bitte rechne selbst nach oder erstelle ein Minimalbeispiel.

Das kann ich so bei allen meiner verkauften ETFs bestätigen. Andere Positionen, die in Bruchstücken vorliegen, werden auch ohne Tooltip bis auf die 3te Nachkommastelle angezeigt.
02
Vielleicht musst du dir wirklich die Mühe machen und nochmal alle 23 Tranchen + Verkauf durchgehen…
Ich hatte auch schon meine Mühe Ungereimtheiten zu tracken. Der Weg ist das Ziel :sweat_smile:

Korrekt, die Differenz beträgt 0,0004 Stk.

  • Alle Buchungen wurden per Import hinzugefügt.
  • Ich bin alle Buchungen durchgegangen, alle Stückzahlen wurden korrekt übernommen
  • In der Gesamtsumme macht PP daraus aber 0,0004 Stk. mehr.

grafik grafik

Minimalbeispiel habe ich zu den Screenshots erstellt. Kann ich zur Not hochladen, enthält m. E. aber nicht mehr Informationen als die geschilderten.

1 Like

Ich kann dir leider nich weiterhelfen :confused:

Mach das. Infos sind immer gut :smiley:

1 Like

Was sagt Dein Taschenrechner, wenn Du die Stückzahlen aufaddierst?

Lad mal hoch. Wenn ich das bei mir reproduzieren kann, dann kann ich mit dem Debugger schauen was schief geht. Nur mit den Screenshot geht das nicht.

Dann schau mal hier…

minimalbeispiel.xml (126,0 KB)

1 Like

Ich weiß nicht, was der Taschenrechner von @networx sagt, meiner sagt:

Du hast in Deinem Portfolio Käufe mit folgenden Stückzahlen:

  • 1.2826
  • 4.2928
  • 4.2928
  • 4.2928
  • 4.2928
  • 4.2928
  • 1.2070
  • 4.0234
  • 4.0234
  • 4.0234
  • 4.0234
  • 4.0234
  • 4.1085
  • 4.1085
  • 4.1085
  • 4.1085
  • 4.1085
  • 1.2178
  • 4.0593
  • 4.0593
  • 4.0593
  • 4.0593
  • 4.0593

Das sind in Summe 86,1274 Stück und das ist auch die Zahl, die Dir in PP angezeigt wird.

Dann hast Du einen Verkauf über 86,127 Stück. Wenn Dir Deine Bank sagt, dass 86,1274 - 86,127 = 0, dann ist das eher ein Thema für Deine Bank als ein Fehler von PP.

Ein anderes Thema ist möglicherweise, dass Käufe und Verkäufe zwei verschiedenen Wertpapieren zugeordnet sind. Das ist ein anderes Thema. PP bekommt es nicht mit, wenn sich die ISIN eines Wertpapiers ändert, wie es hier der Fall war. Das musst Du selbst korrigieren (vor oder nach dem Import der Buchungen mit der neuen ISIN).

3 Like

Korrekt Thomas.

Das es sich um zwei Wertpapiere bzw. unterschiedliche ISIN handelt hatte ich korriegert, habe es aber der Überschicht halber im Minimalbeispiel drin gelassen.

Genau hier liegt aber scheinbar der Hund begraben. Es gab zu dem Papier im November eine Kapitalmassnahme. Lyxor hat ETFs zusammen gelegt und FR0011079466 wurde 1:1 gegen LU1829220216 getauscht.

Sollte zumindest … onvista hat jedoch 86,1274 Stk. ausgebucht aber nur 86,127 Stk. wieder eingebucht. Dementsprechend konnten dann auch nur 86,127 Stk. veräußert werden.
Ich bin mit onvista in Klärung. Hat jemand Erfahrung mit solchen Themen?

Danke für die geduldige Unterstützung an alle!

1 Like

:astonished: Interessant… Bin gespannt was Du rausfindest.

Ich würde - nur zunächst und um die Datei konsistent zu halten - die Verkaufsbuchung einfach um die 0,0004 Stück erhöhen.

Hallo zusammen,

ich habe ein ähnliches Problem und finde leider keine Lösung.

Ich habe ebenfalls ein OnVista-Depot und habe meine Wertpapierabrechnungen importiert.
Leider stimmt der Kaufwert in meinem Depot nicht mit meinem Einstandspreis in PP überein.

Beim zweiten Versuch habe ich die Buchungen manuell eingetragen, selbes Ergebnis.
Ich als Laie würde es auf auf die fehlenden Nachkommastellen schieben -> Rundungsfehler.

Gibt es hierfür eine Lösung?

Danke im Voraus! :hugs:

Grüße,
Seesi

Anhand von einem Bild lässt sich schlecht nachrechnen…

Guten Morgen,

anbei die Datei.

Viele Grüße,

Seesi

MinimalBeispiel.xml (98,9 KB)

Guten morgen Seesi,

vielen Dank für das Beispiel, ich habe es mir gerade angesehen.

Auf die schnelle sind bis auf den letzten Cent die Beträge zwischen PP und Onvista identisch, nur das PP inklusive und Onvista exklusive Gebühren rechnet.

Gruß
Marco

Hallo Marco,

stimmt! Danke, nach Mitternacht Rechnen ist nicht ganz so schlau. :smiley:
Hm… gibt es hierfür eine Lösung? Wie handhabt ihr das mit euren ETF´s oder Aktien?
Wenn ich die Gebühren aus den Buchungen nehme, habe ich den richtigen Kaufwert, aber die falsche Abbuchung von meinem Konto. Gibt es hierfür vllt eine Einstellung? (Inkl. / Exkl. Gebühren anzeigen?)

Grüße,
Seesi | Phillip