ich bin ganz neu hier, gleich ma als Feedback: Der Import mit Scalable Capital / Baader Bank hat beim ersten mal geklappt und es wird alles korrekt dargestellt (6 ETF Sparpläne)
Die „Benutzererkennung“ (Baader Bank) muss in beide Felder „Teilnehmernummer“ und „Kundennummer“ (Rentablo)
Die „initiale PIN“ wurde per verschlüsseltem Mailanhang von der Baader Bank verschickt, mit ihr muss man erst eine Erstanmeldung machen und dann einen neuen PIN wählen.
Den trägt man dann bei Rentablo ein.
Dieses Wochenende hab ich ein bisschen Zeit gefunden und mit dem Depot rumgespielt und glaube dem Übel auf den Grund gekommen zu sein. Nochmal als Rekaputilation - folgendes Problem:
Der Saldenverlauf des Verrechnungskontos des Scalable-Depots läuft (ab Beginn) gern mal ins Negative, egal ob „Negative Kontostände ausgleichen“ angehakt ist oder nicht. Die Option scheint nichts zu ändern. Sieht dann so aus (und ist ziemlicher Quatsch )
Viele der importierten Buchungen des Verrechnungskontos werden mit Wertpapierkäufen verlinkt und korrekt erkannt. Einige (ca. 30% aller Buchungen) jedoch nicht, was dann von Rentablo fälschlicherweise als Einzahlung bzw. Auszahlung erkannt wird. Ich habe nun ALLE diese Buchungen manuell Wertpapierkäufen und Verkäufen rückwirkend zugeordnet und somit keine Geisterpapiere mehr im Depot.
Was nun noch an Cashtransaktionen übrig bleibt muss m.M.n. des Übels Wurzel sein.
Diese werden abwechselnd als Einzahlung oder Abhebung verbucht, haben aber irgendwie nichts mit der Realität zu tun. Die Summe dieser Zwischensalden ergibt sich am Ende zu 4267,04€. Warum erwähne ich das?
Die Erste Buchung, die sich im Verrechnungskonto findet, und die sich auch nicht entfernen lässt, ist eine „Ausgleichsbuchung“ die von Rentablo erstellt wurde (und sich leider nicht löschen oder modifizieren lässt) und auch gegenüber der Check-Box „Negative Buchungen Ausgleichen“ resistent erweist. Und diese Buchung ist „fast“ genau dieser Betrag, nur negativ.
Es ist schon kurios - warum habe ich eine Ausgleichsbuchung mit negativem Wert zur Vermeidung von negativen Kontoständen, die Zwischensalden ausgleicht, die an sich gar nicht in der Berechnung auftauchen sollten?
Ich glaube an dieser Stelle komme ich nicht mehr ohne Unterstützung weiter. Irgendwelche Ideen? Ich helfe gern bei der Aufklärung des Rätsels mit. Ein Löschen und Neuanlagen des Depots hat übrigens überhaupt keinen Effekt darauf.
die Zwischensalden kommen nicht von uns, sondern von der finAPI. Wir werden prüfen, ob wir diese nicht besser entfernen sollten. Generell werden diese angelegt, wenn Kontostand und Transaktionshistorie nicht zusammenpassen.
Da die Zwischensalden nicht 0 ergeben, gleicht Rentablo dann diesen Wert aus.
Ich muss mich noch ein wenig Gedanken machen - aktuell erscheint mir die beste Lösung, die Zwischensalden in einer Migration zu löschen.
Viele Grüße und Danke für das umfangreiche Feedback,
Wolfram
Wenn ich etwas tun kann, um zu unterstützen, lass es mich bitte wissen. Ich habe keine Ahnung wie ich eine Migration mache und dabei Salden lösche … Müsste ich das wissen?
Danke für die Blicke hinter die Kulissen bisher.
Viele Grüße,
Jan
ein ähnliches Problem habe ich vermutlich auch. Bis Januar Februar funktionierte die Übertragung der Depotdaten von der Baaderbank reibungslos. Während der technischen Probleme wurden die Daten nicht mehr übertragen. Als im April eine Lösung gefunden wurde, wurden die fehlenden Umsätze nicht 1:1 übertragen sondern lediglich die Differenz anhand geschätzter Kurse. Dies habe ich von Hand korrigiert, in dem ich das Depot gelöscht habe und neu eingerichtet habe. Es waren mehrere Dutzend Käufe und Verkäufe. Das Verrechnungskonto wurde automatisch aktualisiert. Nun sind viele Buchungen doppelt und ich habe dutzende Saldendifferenzbuchungen.
Haben Sie einen Praktikertip für mich?
Zum zweiten hat Vestas die WP-Gattung umgestellt. Wie gebe ich den Tausch korrekt ein?
wir haben mittlerweile einen nativen scalable.capital import. Das Feature ist zwar noch „beta“, funktioniert aber bereits jetzt besser als der Import über die Baader Schnittstelle.
Zum zweiten hat Vestas die WP-Gattung umgestellt. Wie gebe ich den Tausch korrekt ein?
Meine Daten von der SC.import vs Baader.import sind tatsächlich leicht verschieden.
(Wertpapiere und Kontostand ist gleich). Aber Verluste und Performce ist leicht anders…
Ja, wir empfehlen von nun ab generell den SC Import.
Leider schafft Baader es bis Heute nicht, uns einen Transaktionstyp mitzuschicken. Daher ist es z.T. schwierig, zwischen Dividende und Kauf zu unterscheiden.
Nein, der neue Import verwendet einen Web-Scraper der alle Transaktionstypen korrekt listet.
Ich habe hier beim neuen SC.import eine Position vom 25.05 wo steht:
„Verkauf. Es ist keine Bank-Transaktion zugewiesen. Problem jetzt korrigieren.“
Es sieht aus, wie wenn es hier einen Storno gegeben hätte? Könnten Sie das einmal prüfen.
Wir sind bei solchen Sonderfällen noch beim „Feintuning“. Ich würde mich über eine Rückmeldung hierzu freuen
Also irgendwie ist am 4.5 von Rentablo die die Storno nicht erfasst worden.
Und dann plötzlich am 24.5 als Verkauf gebucht. Aber die vollen 3,162 Stk, nicht die 1,617 Stk…
vielen Dank für die Rückmeldung, das erscheint mir alles Plausibel.
2 x 1,581 sind dann genau die 3,162 Stk. zuviel.
Wir haben der finAPI bereits Rückmeldung gegeben und hoffen, die Stornos zukünftig korrekt erkennen zu können. Das muss aufseiten der finAPI korrigiert werden, da die Transaktion im Moment falsch klassifiziert wird - für uns gibt es kein Unterscheidungsmerkmal.
erstmal vielen herzlichen Dank für die Neu-Aufsetzung des Scalabale Reports und der Web-Scrapers. Das scheint viele Dinge deutlich besser hin zu bekommen, jedoch möchte ich neben dem positiven Feedback auch noch einen Blick auf die Probleme werfen, die mir bisher aufgefallen sind.
Saldenverlauf des Verrechnungskontos
Nach frischem Import des Depots und des Verrechnungskontos sieht das erstmal so aus.
Ursache hierfür ist wieder eine negative „Ausgleichsbuchung“ ganz am am Anfang der Buchungshistorie, die ich einfach nicht los werden kann. Ein ähnliches Problem plagte mit auch schon zu Zeiten von Baader-Bank Importen.
Egal, was ich unternehme um das los zu werden, ich scheitere (Manuelle EInzahlung als Gegenbuchung, Umdeklaration der Buchung oder gar Löschen der Buchung oder Löschen Aller Cash-Transaktionen).
Ursprung der Buchung ist übrigens ein nicht ordentlich erkannter Depot-Transfer bzw. die Einlieferung von ETFs, die Ihrerseits nicht als Kauf sondern als „Einzahlung“ erkannt wurden.
Kannst Du bitte nochmal einen Blick drauf werfen? Gibt es etwas, das ich tun kann?
Ich würde wirklich gern dazu beitragen, dass das funktioniert und glaube auch, dass Depot-Transfers in Scalable hinein in Zukunft weiter relevant bleiben werden.
wir sind aktuell mit der finAPI zu Gange. @JME23: könntest Du mir den Konstostand und ggf. die tatsächliche Transaktionshistorie an stacklies@rentablo.de senden? Wir würden das dann mit den Daten von finAPI abgleichen.
Hintergrund:
Es ist leider tatsächlich so, dass die Summe der gelieferten Transaktionen total vom gelieferten Kontostand abweicht. Da wir uns leider auf den gelieferten Kontostand verlassen müssen, muss die Lösung wohl von der finAPI kommen.
Warum? Oft beginnt die Transaktionshistorie irgendwo, und dann müssen wir auf Basis des Kontostandes zurückrechnen.
Beispiel:
Du hast ein Konto seit 10 Jahren
Die Bank liefert uns beim Import die letzten 12 Monate
dann rechnen wir entsprechend zurück und erstellen eine Ausgleichsbuchung.
Also: wir sind dran, müssen aber gemeinsam mit der finAPI eine Lösung finden.
nochmals eine kurze Rückmeldung: das Problem ist, dass finAPI Einbuchungen als Cash-Transaktionen ansieht, und das führt dann zu einer falschen Summe.
Wir haben jetzt zum dritten Mal versucht, dem entsprechenden Entwickler den Unterschied zwischen einem Kauf und einer Einbuchung zu erklären. Wir prüfen zusätzlich, ob wir nicht kurzfristig einen Workaround bauen können.
Ich kann mich meinen Vorrednern nur anschließen, prinzipiell schon mal ein sehr guter erster Ansatz und zusammen lassen sich bestimmt auch noch die letzten Schnitzer, die sich durch die seltsamen Daten von Baader Bank und Scalable ergeben ausmerzen.
Damals gab es ja beispielsweise mal „doppelte“ Sparplanausführungen… Gesamtsaldo vom V-Konto war korrekt, aber das hat sich leider aus den einzelnen Transaktionen nicht ergeben… denn die doppelte Buchung war da, aber keine „Korrekturbuchung“. Nach unzähligen Beschwerden bei Scalable und Baader Bank gab es nun bei den leider erneut aufgetretenen doppelten Ausführungen zumindest auch eine ersichtliche Korrekturbuchung! Nur nach meinem letzten Stand bisher nicht rückwirkend… aber das spielte vermutlich nur bei der Baader Bank FinTS Schnittstelle eine Rolle. Damals kamen dann auch teilweise die Käufe nicht einzeln sondern etwas verklumpt an… so dass sich keine gleichmäßige Treppenform bei der Portfolioentwicklung eingestellt hat… Da weiß ich gar nicht mehr genau woran es lag. Alter Kaffee - schwamm drüber.
Die Transaktionshistorie im Scalable WebUI reicht bisher zum Glück bis zum Anfang zurück (Juni 2020).
wir haben nun eine ganze Reihe an Verbesserungen am Scalable Import vorgenommen. Hierzu gehören
Ein- und Ausbuchungen werden korrekt erkannt
Ein- und Ausbuchungen tauchen auf dem Verrechnungskonto jetzt korrekt als „0 Euro“ Transaktion auf; zuvor erzeugten diese eine falsche Transaktion in Höhe des Einbuchungswertes
Zwischensalden werden nicht mehr übernommen, da diese i.d.R. auf einer falschen Dateninterpretation Seitens der finAPI beruhen
In Summe sind damit jetzt die Kontostände korrekt und die Transaktions- / Buchungshistorie sollte sauber übernommen werden.
Da es doch eine ganze Reihe an Datenfehlern gab, empfehle ich, das Scalable Depot und Verrechnungskonto zu löschen und dann nochmals neu zu importieren.
Aufgrund der Komplexität der Daten ist es schwierig, das im Rahmen einer Migration zu korrigieren; insbesondere da auch unser Partner finAPI Verbesserungen vorgenommen hat.
)
