PreRelease .238: Stückzahl in Order wird nach Kursaktualisierung auf Null gesetzt

1. offizieller Beitrag

    Im Prerelease .238 wird die Stückzahl in einer älteren Order nach der Kursaktualisierung auf Null gesetzt. Löschen und Neuanlegen der Order hilft nicht. Neuere Ordern mit der gleichen WKZ (WKN 965515, Gold in USD) sind nicht betroffen. Die betroffene Order weist als Besonderheit auf, dass der Kaufkurs extrem niedrig ist. In Version .215 tritt dieser Effekt nicht auf.
    gruß
    rowi

    Letzter Stand:

    • MG 2015 beendet und neu gestartet
    • Devisen- und Kusaktualisierung durchgeführt; Stückzahl wird auf Null gesetzt.
    • Löschen der Order, Neuanlegen mit "normalem" Kaufkurs
    • Erneut Aktualisierung; Stückzahl bleibt erhalten
    • Kaufkurswert der Order auf "niedrigen" Wert zurückgesetzt
    • nach Devisen- und Kursaktualisierung bleibt die Stückzahl jetzt erhalten
    • auch nach Neustart und erneuter Aktualisierung kein Fehler mehr

    Die Order bleibt in den nächsten Tagen erstmal unter Beobachtung.
    Gruß
    rowi

    Ticket beim Support einreichen. Klingt, als wenn eine Logik-Prüfung eingebaut wäre, die diesen Kurs als unrealistisch beurteilt und die Buchung damit als ungültig erklärt. Sollte, wenn überhaupt, nur mit einer Warnung einhergehen, die evtl so lauten könnte "Kurs und Stückzahl, sowie Datum zu dieser Buchung bitte prüfen! Besonders hohe Kursabweichung! Bitte bestätigen Sie diese Buchung."


    Falk

    Auch im PreRelease .240 bzw. inzw. im offiziellen Release .240 existiert dieser Fehler. Bei mir wird reproduzierbar die Stückzahl der 1. Orderbuchung in einem Wertpapierdepot auf "0" gesetzt, wenn ich den Kurs aktualisiere oder wenn ich einfach nur zwischen den Reitern "Vermögensübersicht" und "Orderhistorie" hin und her wechsele (ohne irgendetwas zu ändern).


    Ich habe ein Ticket dazu eröffnet und Screenshots eingesandt.

    Hallo, ich habe bei meinem Depotabruf bei der UnionInvest ebenfalls unsinnige werte. Die Kurse scheinen einen Kommafehler zu haben. Es gab vor kurzer Zeit ein Update - seit dem "Spinnt" mein Geld etwas. Außer dem hat das Programm eine Buchung zu einem anderen Empfänger zugeordnet.

    Ich kann nur die Feststellung von ROWI bestätigen. Es geschehen seltsame Dinge mit den Ordern.
    Die Anzahl der georderten Aktien/Fondsanteile wird auf 0 gesetzt, in einem Fall habe ich jetzt eine negative Anzahl von Fondsanteilen im Depot, bei einer Position, die bereits vor 2 Jahren verkauft, also auf 0 ist.
    Insofern stimmt auch keine Auswertung zu Gewinnen und Verlusten mehr.
    Ich meine, daß es zu dem Fehler kommt, wenn man in die Orderhistorie geht, aber das ist nicht gesichert.


    Ich glaube, daß die Probleme mit dem Release auf 20.3.0.240 angefangen haben, kann das aber nicht belegen.


    Ich habe mir (jetzt schon mehrmals) mit dem Zurückspielen einer Datensicherung geholfen, dann war es wieder korrekt. Das kann ja nicht die Lösung sein.


    Hat jemand ein Ticket bei Buhl aufgemacht?


    Gruß
    Wolf

    Ich kann seit dem letzten Update dieses Verhalten ebenfalls beobachten.


    Die Anzahl der Aktien der ersten Order in einem Depot wird auf null gesetzt, wenn ich manuell eine neue Order eingebe oder eine Order erzeugt wird, weil sich die Anzahl im Onlinedepot verändert hat.


    Wenn ich die erste Order anschliessend bearbeite und die Anzahl wiederherstelle, so wird der Wert zunächst korrekt übernommen und auch beim Wechsel der Tabs beibehalten. Beim Wechsel zum Startbildschirm wird die Anzahl aber wieder auf null gesetzt. Die passiert reproduzierbar. Beendet man das Programm nach der Korrektur und startet wieder neu, bleibt die Order beim korrekten Wert.


    Kurs-/Devisenaktualiesierungen zeigen kein Fehlverhalten bei mir.


    Version: 20.3.0.240

    Ich habe heute das Release .241 eingespielt und meine gesicherte MG-Datei vom 17.2. (vor Upgrade auf .240) genutzt. Der Fehler, dass die Stückzahl der 1. Order in einem Wertpapierpapier nach einem "Tab-Wechsel" auf "0" gesetzt wird, tritt bei mir jetzt nicht mehr auf. Ich bekam auch einen entsprechenden Hinweis zu dem Ticket, dass ich aufgemacht hatte (Problem gelöst in .241).