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.
Hallo @wolframst ,
Ok, super. Dann lösche ich den Baader.import raus.
Das gilt auch für den neuen SC.import?
Ich habe hier beim neuen SC.import eine Position vom 25.05 wo steht:
„Verkauf.
Es ist keine Bank-Transaktion zugewiesen. Problem jetzt korrigieren.“
Allerdings habe ich nichts verkauft… auch nicht gekauft zu dem Zeitpunkt…deswegen kann ich den Eintrag nicht nachvollziehen…
Das gilt auch für den neuen SC.import?
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 
Es sieht aus, wie wenn es hier einen Storno gegeben hätte?
Hm. Ich kann keinen Storno entdecken in der SC Transaktionsübersicht, die dazu passen würde…
Wüsste auch nichts von einer solchen Storno…
Aber es muss wohl mit einer Storno zu tun haben…
Folgendes sehe ich in der
SC in der Transaktionsübersicht zum betreffenden ETF:
7.4
(1) Sparplan: Ausgeführte Stückzahl 3,162
(2) STORNO: Ausgeführte Stückzahl: 1,581
4.5
(1) Sparplan: Ausgeführte Stückzahl 1,617
TOTAL: gehaltene Teile: 3,198
(sonst nichts, auch nicht am 25.5)
Transaktionsübersicht laut Rentablo:
7.4:
Kauf 1,581 Stk
Kauf: 3,162 Stk
4.5
Kauf: 1,617 Stk
24.5
Verkauf: 3,162 Stk
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…
Lieber @getitdone,
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.
Ich melde mich an dieser Stelle dann zurück.
Viele Grüße,
Wolfram
1 Like
Super. Danke dafür. Dann warte ich auf das Update dazu hier an dieser Stelle. Danke!!
Hallo @wolframst,
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.
Viele Grüße,
Jan
Lieber @getitdone,
die finAPI meldet, das Problem der Stornos gelöst zu haben.
Allerdings müsste hierfür wohl ein neuer Import der Transaktionen stattfinden.
Wäre es möglich, dass Sie nochmal ganz neu importieren und mir dann kurz Rückmeldung geben. Dann kann ich das prüfen.
Gruß,
Wolfram
Lieber @JME23,
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.
Lieber @JME23,
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.
Gruß,
Wolfram
1 Like
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).
Hallo Zusammen,
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.
Viele Grüße,
Wolfram
Gelöscht und neu hinzugefügt.
2 Probleme:
21Shares Bitcoin ETP Bestand falsch hinterlegt (CH0454664001), viel zu niedrig, da ein zu hoher seltsamer Verkauf unter Transaktionen anstelle der zwei real stattgefundenen. Stelle gerne Transaktionen aus extraETF und Scalable zur Verfügung. (PS: Der 21Shares Ethereum ETP wird wie ein normaler ETF verbucht (bzw. als Zertifikat) aber der Bitcoin ETP mit Nennwert, Kurs in % etc. (Anleihenmäßig))
Durch offene Order geblockte Beträge weiterhin nicht im Gesamtvermögen enthalten.
Nach erneuter Aktualisierung kamen noch ein paar Transaktionen und ein 3. Problem hinzu IE00B4L5Y983 dieser wurde 12x bespart und sonst nie gehandelt, es tauchen dennoch große Verkäufe hierzu auf.
Lieber @muhkuhrt,
21Shares Bitcoin ETP Bestand falsch hinterlegt (CH0454664001), viel zu niedrig, da ein zu hoher seltsamer Verkauf unter Transaktionen anstelle der zwei real stattgefundenen. Stelle gerne Transaktionen aus extraETF und Scalable zur Verfügung. (PS: Der 21Shares Ethereum ETP wird wie ein normaler ETF verbucht (bzw. als Zertifikat) aber der Bitcoin ETP mit Nennwert, Kurs in % etc. (Anleihenmäßig))
Das bereitstellen der „korrekten“ Transaktionen aus Scalable würde mir sehr helfen. Bei Anleihen / Produkten die in % notieren müssen wir noch genau herausfinden, was Scalable uns liefert. Das ist leider immer etwas kompliziert.
Beim CH0454664001 konnten wir das Problem allerdings bereits identifizieren. Und zwar ist das ein Stammdatenfehler bei unserem Kursdaten-Anbieter. Das Produkt wird als „in Prozent“ notierend klassifiziert. Daher der Fehler. Wir haben bereits eine Korrektur der Stammdaten angefordert.
Durch offene Order geblockte Beträge weiterhin nicht im Gesamtvermögen enthalten.
Das Thema hatten wir noch nicht angegangen. Wir klären noch, ob dies unterstützt werden kann.
Nach erneuter Aktualisierung kamen noch ein paar Transaktionen und ein 3. Problem hinzu IE00B4L5Y983 dieser wurde 12x bespart und sonst nie gehandelt, es tauchen dennoch große Verkäufe hierzu auf.
Wir prüfen auch das.
Beim CH0454664001 konnten wir das Problem allerdings bereits identifizieren. Und zwar ist das ein Stammdatenfehler bei unserem Kursdaten-Anbieter. Das Produkt wird als „in Prozent“ notierend klassifiziert. Daher der Fehler. Wir haben bereits eine Korrektur der Stammdaten angefordert.
So etwas dachte ich mir schon, sind der 21Shares Bitcoin und Ethereum ETP ja eigentlich vom gleichen Typ und erscheinen auch völlig identisch in den Transaktionen bei Scalable. Ich bin jedoch noch nur zurückhaltend optimistisch, dass das eine mit dem anderen (der fälschlichen Zusammenfassung von Ordern, siehe Screenshots per Mail) zu tun hat. Das Problem scheint woanders gelagert.
Durch offene Order geblockte Beträge weiterhin nicht im Gesamtvermögen enthalten.
Das Thema hatten wir noch nicht angegangen. Wir klären noch, ob dies unterstützt werden kann.
Hierfür sollte es zwei mehr oder weniger sinnvolle Möglichkeiten geben: Aktuell dürfte für das Verrechnungskonto das „Guthaben“ herangezogen werden. 1. Einfache Möglichkeit: Stattdessen Den gesamten Portfoliowert der ebenfalls angezeigt wird MINUS den Wertpapierbestand heranziehen oder 2. weniger sinnvolle und aufwendigere Möglichkeit: Den vorgemerkten Ordern sollten ebenfalls analog zu den ausgeführten Stückzahl und Limitpreis entnommen werde können und somit einfach zum Cashbestand addiert werden können.
Nach erneuter Aktualisierung kamen noch ein paar Transaktionen und ein 3. Problem hinzu IE00B4L5Y983 dieser wurde 12x bespart und sonst nie gehandelt, es tauchen dennoch große Verkäufe hierzu auf.
Dieses Problem beruhte auf 0-EUR Buchungen, die uns aus irgendeinem Grund übermittelt werden. Das hat beim Import zu einem Fehlerfall geführt. Wir haben das Problem nun behoben.
Bezüglich des CH0454664001 warten wir auf eine Stammdaten-Korrektur des Kursdaten Anbieters.
Hallo zusammen,
für mein Broker-Depot klappt alles gut soweit. Allerdings bin ich derzeit nicht in der Lage mein zweites Scalable-Depot (Vermögensverwaltung) zu importieren. Der Zugriff erfolgt unter identischen Zugangsdaten. Jedoch wird stets nur das Broker-Depot erkannt. Hat jemand einen Tipp? 
Viele Grüße
Tim
Lieber @Tim,
das ist ein bekanntes Problem. Wir arbeiten aktuell gemeinsam mit unserm Partner finAPI an einer Lösung für VV Depots. Sobald verfügbar, werden wir hierüber informieren.
Viele Grüße,
Wolfram
2 Quartale später erlaube ich mir die Frage: Gibt es diesbezüglich schon Neuigkeiten?
Gibt es aktuell Schnittstellen Probleme? Seit 3.1. werden meine Zugangsdaten nicht akzeptiert. Fehler 422