Historische Kurse bei manueller Einlieferung, Kauf etc

Dieses Thema betrifft wohl vor allen Dingen die Abbildung eines existierenden Portfolios für neue Benutzer.

Wenn man eine neue Einlieferung oder einen Kauf für ein Wertpapier in einem Depot eintragen will, so “ignoriert” das Programm das gewählte Datum in Bezug auf den Kurs völlig. Mein Wertpapier hat (per CSV importierte) historische Kurse. Aber egal, welches Buchungsdatum ich im Dialog wähle, die Vorbelegung des Stückwerts ist immer der aktuelle Kurs.

Hier wäre es sehr wünschenswert, wenn der Kurs sich mit dem Datum anpasst. Jedenfalls, solange der Wert im Feld dem aktuellen Wert entspricht (also noch nicht manuell angepasst wurde). Das würde den Zeitaufwand enorm reduzieren. Man hat aktuell auch das Problem, dass man sich den historischen Kurs (z.B. das CSV) parallel öffnen muss, da die Depotansicht den Wertpapier-Kurs ja nirgends gleichzeitig zeigt.

Warum? Du musst doch so oder so den realen Kurs, zu dem du gehandelt hast, eintragen; nicht irgendeinen Schlusskurs von dem Tag, der nur ähnlich ist.

Hallo JanB,

so ganz habe ich den geschilderten Sachverhalt nicht verstanden

Jein. Prinzipiell hast du recht, man muss den echten Kurs eh eintragen. Das gleiche Argument greift ja aber beim aktuellen Kurs (der vorbelegt wird) genauso. Auch bei Buchungen “Jetzt”/“Heute” stimmt der vorgeschlagene Kurs ja nicht wirklich. Warum gibt es trotzdem einen Vorschlag, und warum macht er auch bei historischen Sinn?

  1. Es kann sein, dass man eh zum Schlusskurs gekauft hat, dann passt’s
  2. Es kann sein, dass das Wertpapier gar nicht frei gehandelt wird und daher nur Tageskurse hat (mein Fall)
  3. Der historische Kurs ist sicher dichter am echten Kaufkurs als der aktuelle. D.h. man muss wahrscheinlich weniger am Kurs ändern (z.B. statt komplett tippen nur die Nachkommastellen korrigieren)

Ich glaube mittlerweile, das ist sogar ein Bug. Denn trägt man erst das Datum ein, und wechselt dann in der Kombobox auf das richtige Wertpapier, dann WIRD der historische Kurs in das Kursfeld eingetragen. Es klappt nur nicht, wenn man erst das Wertpapier wählt und dann das Datum, oder wenn man z.B. per “Speichern & Neu” zur nächsten Eingabe übergeht.

Da eh nur die Stückzahl und der Wert der Buchung für alle Berechnungen relevant ist, kann ich keinen Bug erkennen. Es ist ein Vorschlag, wenn nur Stückzahl und Kurs bekannt ist. Da recht schnell der Positionswert gesetzt wird, wird der Kurs nur noch durch die Änderung der Stückzahl oder Gesamtwert beeinflusst.

Meiner Meinung nach ist es völlig irrelevant, welcher Kurs vorbelegt ist. Der Schlusskurs war bei mir noch nie der Kaufkurs und ob man nur die Nachkommastellen ändert oder gleich den kompletten Kurs, zu dem der Kauf getätigt wurde - naja, das ist ja eh in einer Sekunde erledigt. :wink:

Edit: Ich fänd das Verhalten sogar anfällig für Flüchtigkeitsfehler, wenn die Anwendung nach der Datumsauswahl nochmal den Kurs ändern würde.
Wenn man einen Kauf bucht, trägt man den tatsächlichen Ausführungspreis ein. Stellt man dann fest, dass das Buchungsdatum vergessen wurde oder man sich beim Datum vertippt hat und passt dieses an und der Kurs würde sich automatisch zu dem Schlusskurs des Datums ändern und man übersieht das, dann kann man später auf Fehlersuche gehen, wenn man sich irgendwann wundert, warum das tatsächliche Verrechnungskonto nicht mehr den identischen Wert zu PP hat. Zugegeben bisschen konstruiertes Beispiel, aber könnte passieren. :smile:

I’m seltenen Fall, dass ich Mal einen Kauf manuell buche, habe ich noch nie den Kaufkurs eingegeben. Wofür macht ihr dass denn? Gebt doch die Anzahl und den Betrag ein, Rechnen kann der Computer. Dann gibt es gar kein Risiko sich beim Kurs zu vertippen.

Ich denke, es ist unerheblich, ob man Anzahl und Betrag eingibt oder Anzahl und Kurs. Wenn bei einer späteren Datumskorrektur systemseitig der Kurs verändert werden würde, verändert das auch den Betrag. Darauf wollte ich nur hinaus. (Auch wenn das selten vorkommen mag.)

Ob es schneller/sicherer ist, Kurs oder Betrag einzutippen, weiß ich nicht. Man rechnet doch bei beidem nicht , sondern prüft nur, ob das nicht selbst eingetippte danach passt?

Das Szenario verstehe ich noch nicht 100%. Selbst wenn sich der Tag ändert (wie auch immer das gehen soll), bleiben doch Anzahl, Kaufkurs und Betrag der gleiche. Ansonsten kann es doch nur eine andere Buchung sein, oder?

Richtig. Wobei auch da kontrolliere ich nie den Kurs, weil der irrelevant ist und immer richtig berechnet wird (häufiger runden die Banken auf ihren Abrechnungen).

In meinem Fall aber schon, bzw. gab es hier einfach nur einen fixen Tageskurs.

Nein. Da kann ich dir als Entwickler sagen, dass man sowas natürlich so umsetzt, dass eine Datumsänderung nur dann eine Kursänderung auslöst, wenn noch kein Kaufpreis eingetragen wurde.

Zur Frage, warum man überhaupt den Kurs eintippt statt den Kaufpreis. In dem abgebildeten Fall war nur Stückzahl und Kurs bekannt, nicht die Summe. Die hätte ich ausrechnen müssen.

Diese ganzen Diskussionen sind aber müßig: Das Programm macht das ja alles schon, was ihr in Frage stellt. Vermutlich Andreas hat ja bereits bei der Entwicklung entschieden, dass Kurse mit historischen Werten vorbelegt werden sollen. Allerdings passiert das aktuell nur beim Wechsel des Wertpapiers. Und das ist schlicht inkonsistent. Man belegt ein Feld vor, dass sich aus Datum + Wertpapier ergibt. Es macht wenig Sinn, das dann nur beim Wechsel einer der beiden Faktoren zu tun, beim Wechsel des anderen aber nicht. Es wäre was anderes, wenn, wie zunächst gedacht, IMMER der aktuelle Wert belegt werden würde. Dann wäre meine Anfrage hier ein Erweiterungswunsch. Aber da bereits der historische Kurs belegt wird, aber nur abhängig davon, ob man jetzt (zufällig, denn die Logik kennt man als User ja nicht) Faktor 1 oder Faktor 2 zuerst im Dialog wählt, dann ist das inkonsistente UI Logik.