Import von Fidor .CSV Dateien in B4W

daß B4W seit einem der letzten Updates sehr lahm wurde kann ich ja noch verschmerzen (auch wenn es nervt) und daß die Beschreibung der Formate für den .CSV Import so allgemein gehalten sind, daß sie nur sehr bedingt aussagekräftig sind, ist im Extremfall zeitaufwendig (nur durch probieren konnte ich Cristal Card Umsätze importieren), aber daß ich bei der Fidor-Bank anscheinend keinerlei Umsätze (weder fürs Konto noch für die Mastercard) über .CSV Dateien importieren kann entwickelt sich so langsam zum KO-Kriterium für B4W.

Oder hat es jemand geschafft Fidor Umsätze per .CSV Datei in B4W zu importieren?

Ich denke mal, der Kundenkreis dieser sog. Banken, die entgegen den Wünschen der Bankster B4* (oder irgend ein anderes Bankingprogramm) verwendet ist dermaßen überschaubar, daß es sich für Hersteller einfach nicht lohnt, für diese Extra-Würste zu braten. Es ist ja explizit alles auf die Website und evtl. noch mobile Eigen-Apps ausgerichtet, dass die braven Kunden das dann auch so machen, wie sie es sollen. Und sich natürlich jedesmal die unschlagbaren Sonderangebote anschauen und hoffentlich auch kaufen. Damit das auch so bleibt, ändert man dann auch regelmäßig die Web-Dialoge, damit bei ungebliebter Software jedes Mal nachgearbeitet werden muß. So treibt man das Programmbanking dann auch den letzten störrischen Kunden aus - und natürlich den Programmentwicklern die Unterstütztung der "Bank".

Ja, wenn er sich erst mal hingesetzt hat, und soundsoviele Manntage in die Entwicklung so einer Oberfläche gesteckt hat. Und dazu hat er nun vielleicht gerade keine Zeit, keine Lust oder einfach ihm Wichtigeres zu entwickeln...
Man könte sich da ja auch die Gegenfrage stellen: Wieso können die Banken nicht mal ein CSV-Format gemeinsam benutzen, wieso muß jede irgendwas anderes erfinden? Klar, weil die EDV-Abteilung jeder Bank die beste ist und es am allerbesten kann. Und weil man eigentlich ja garnicht will, daß der Kunde das nutzt. Aber wieso soll ausgerechnet der Kundenprogrammhersteller das ausbaden? Und das mit dem Zusammenklicken ist ja in versch. Programmen schon so umgesetzt, in NetWorld glaub ich z.B. das schon vor vielen Jahren mal gesehen zu haben. Nur: Damit kommt man in den meisten Fällen heutzutage auch nicht mehr weiter. Weil die sog. CSV-Dateien, die man runterladen kann, hochspeziell und eigentlich keine CSV mehr sind. CSV hat definitionsgemäß eine Anzahl von Spalten, in der ersten Zeile die Feldnamen, in allen weiteren Zeilen die Feldinhalte. Und genau das ist in den Bank-Web-CSVs nicht mehr der Fall. Da sind oben in den ersten Zeilen andere Daten in den Spalten, ob mals eine Art Überschriftsdaten wie Kontosaldo usw., und das mit einem Feldnamen, einem Doppelpunkt und dahinter ein Wert. Und dahinter evtl. in einer extra Spalte noch ein Datum oder ein EUR oder sonstwas. Will heißen, der einfache Weg von früher, wo man sagen konnte "importiere erst ab Zeile 7" geht auch nicht mehr, weil man was von dem Zeug oben drüber benötigt. Bei ganz wieven Bankprogrammierern ist dann der Endsaldo noch UNTER den Daten angesiedelt. Für sowas einen kofigurierbaren Import zu schreiben - viel Spaß. Außerdem werden damit dann die meisten Normalnutzer völlig überfordert sein und dei Supportlawine rollt los. Und für die Wenigen, denen das dann wirklich was nutzt, ist der Aufwand viel zu groß.


Weil's eben kein Standard ist, sondern jeder ach so tolle neue FinTechFuzzi alles ganz anders und viel besser macht als jeder Mensch jemals zuvor. Für einen Dienstleister und seinen Kunden, der darauf einen Shop betreibt und viele Transaktionen abwickelt ist es natürlich sinnvoll, sich auf die API einzulassen und die umzusetzen. Dass Kundenproduktentwickler für jeden Stern, der aufgeht und kurz drauf wieder verglüht eine neue API umsetzen und dann nach Lebensdauerende wegwerfen, damit ist ja wohl nicht zu rechnen. Siehe Österreich, da gibts kein HBCI, also keinen Standard, jede Bank macht ihren eigenen Stiefel, übergreifende Kundenprodukte, die alle oder wenigstens viele Banken unterstützen: Fehlanzeige.


Der Vergleich hinkt! ISDN und VoIP (zumindestens SIP) ist ein Standard. Die grundsätzlich von Bank zu Bank verschiedenen APIs sind es nicht. Mit SIP kannst Du Produkte verschiedener Hersteller zusammenbringen, mit den BankAPIs nicht. Das wäre, wie wenn jeder Telefonanlagenhersteller die internen Protokolle für sämtliche am Markt befindlichen Systemtelefone aller anderen Hersteller unterstützen sollte, damit ich Panasonic-SystemTelefone an Siemens-Anlagen anschließen kann usw. Das wird auch nie passieren... Schon allein aus Patent- und Schutzgründen.

Und: Was würden die tollen FinTechs sagen, wenn irgendwelche Programmhersteller ihre APIs umsetzen und ihre Kunden dann nicht mehr auf ihre Webseiten und Apps kommen würden, und somit die Werbung nicht mehr sehen? Dann gibt's Saures...

@msa
du hast ein Rundumschlag gemacht, mit der Aussage 08/15-Software ist einfach und hardcoded ist halt so
es gibt des weiteren Programme die was anderes/mehr können, dann sollte man halt diese verwenden - hm, die Haltung kann man nachvollziehen, muss sich dieser jedoch nicht anschließen.


wie verarbeitet starmoney das o.g.?

@Raimund
bei paypal muss man bspw. screenscraping nehmen oder halt die API = welche Schnittstelle ist nun weniger fehleranfälliger?
auch die weiteren wie android pay usw. werden entsprechend kommen.
Des weiteren ist ja eine Frage, wo die Schnittstelle zur Verfügung steht B2C oder B2B - die Middleware scheint in jedem Fall sich großer Beliebtheit, da die shopbetreiber einmalig die Schnittstelle schaffen müssen und dann per Transfer bezahlen, egal von wo kommend screenscraping/HBCI/API
(die detaillierten Unterschiede zwischen BTX u. API "heute" kenn ich nicht, da ich kein Programmierer bin bzw. tagtäglich mich damit beschäftige - die Fakten/Zahlen der Unternehmen und auf der anderen Seite Diensteanbieter zeigt jedoch, dass Bedarf vorhanden ist)
aber nochmals, das wurde von dem Threadstarter eigentlich gar nicht angefragt

Wir haben es einerseits mit Schnittstellen zu tun - FinTS/HBCI vs. API-Schnittstelle, aber auch mit Formaten, bei Umsätzen z.B. CSV vs. MT940/CAMT.
Wenn sich das Bessere gegen Bewährtes immer durchsetzen würde, hätten wir nie VHS genutzt und MP3/MPEG2 wäre auch schnell ersetzt worden. Man darf gespannt sein.
Ich denke, konvertieren kann man alles. Nur wer will sich die Mühe machen?

Völlig richtig. Es gilt, den Spagat zu wagen, einerseits Importe anzubieten, mit denen JEDER Kunde auf den ersten Klick zurechtkommt, sich aber nicht zu verzetteln, dass man am Ende die Personenrecourcen allein mit der Wartung der unzähligen Importschnittstellen auslastet.

Das Problem ist nämlich, dass der normale Kunde mit einem Selbstzusammenklick-Import meistens nicht zurecht kommt (ich weiß wovon ich rede, ich hab sowas mal intern supportet), geschweige denn, wenn es ein spezielles Format ist, das oben soundsoviel Zeilen drin hat, die mit den darunter befindlichen Datensätzen nichts zu tun haben. Erstens muß sowas erst mal programmiert werden und zweitens löst es dann Supportbedarf aus, der auch erst mal bezahlt werden muß.

Diesen Spagat für ein Programm wie B4* bei dem derzeitigen Preis zu schaffen ist sehr anspruchsvoll, wenn man nicht pleite gehen will. Dass bei B4* die optische Oberfläche dauernd "überarbeitet" wird, davon bin ich der allererste Kritiker, weil ich der festen Überzeugung bin, dass dadurch NICHTS besser, aber vieles schlechter geworden ist (ggü. der alten Oberfläche). Aber das ist der Mehrzahl der Kunden geschuldet, die es eben "modern" haben wollen. Ich bin mir sicher, Andreas hat sich das alles sehr gut überlegt und deshalb seine Entscheidungen so getroffen wie er es getan hat. Auch wenn wir hier das oft nicht verstehen können.

Meine Empfehlung: geh auf jeden Fall mal auf Fidor zu und zeige Interesse an einem "vernünftigen" Export-Format. CSV ist ja nun wirklich das Gegenteil von "modern", warum sollten eine "moderne" Bank nicht auch CAMT/XML generieren können, es ist nun mal das SEPA-Format und hat Zukunft.

Ansonsten: Konvertieren der Umsätze kannst du über die Testversion geeigneter Programme, wie z.B. mit windata (den Importfilter kann man im Editior per Hand editieren, das fand ich ganz praktisch). Dann exportierst du das in MT940 und schaust mal, ob du das nach B4 einlesen kannst. Oft fehlt beim Import nur der Kontostand, das sollte über einige Excel-Operationen eigentlich zu schaffen sein.

Gruß
Raimund

Ein komplett dokumentiertes Input-Beispiel wäre wohl hilfreich, damit man eine "Zielvorgabe" für entsprechende Umwandlungen per Tabellenkalkulation hat.

Hehe, meinst du diesen uralten Fall:
VWZ1, VWZ2, auch VWZ, auch VWZ,...
Welches Institut war das noch mal, ich finde das nicht wieder.
msa, du bist doch auch schon lange dabei, kannst du dich daran noch erinnern?
Gruß
Raimund

Irgendwie habe ich das mit den Benachrichtigungen noch nicht richtig heraus u d hab wieder nicht bemerkt, daß es Antworten gab.



Dies kann ich alles nachvollziehen und ich denke wenn die bestehenden Filter dokumentiert wären (die Zuordnung zu irgendwelchen Banken hilft Nicht-Kunden dieser Banken kein bißchen weiter) bestünde wenigstens Ansatzweise die Möglichkeit einer Bank zu sagen was als .CSV funktioniert (Fidor bietet ja .CSV an).

Auch bei nem flexibleren .CSV Filter bestünde die Möglichkeit einen Rahmen für die Flexibilität festzulegen und zu dokumentieren (ich kenne sowas z.B. von Excel). Dies würde dann sicherlich nicht alle .CSV Dateien erfassen, aber u.U. einige. Da die Formate nirgendwo dokumentiert sind, ist es leider nicht einfach festzustellen was wenigstens in die Nähe käme und dies ggf. anzupassen. Vielleicht habe ich aber auch die Dokumentation nicht gefunden. Eigentlich wollte ich nur zügig einen Ersatz für Kalixa und nicht wirklich nen Exkurs in Zahlungsdaten.

Übrigens Kalixa fällt in Kürze weg, die machen zum 24. April 2016 dicht