Ich versuche gerade ältere Umsätze, die nicht mehr online abrufbar sind, über eine CSV-Datei zu importieren. Beim Format habe ich mich an den Exportspalten orientiert.

Leider scheint es beim Import noch ein Problem zu geben, da er mir bei manchen Umsätzen die Spalten nicht korrekt trennt, z.B. werden Werte aus der Verwendungszweck2-Spalte in der Verwendungszweck-Spalte mit abgespeichert. Auch der Betrag wird leider nicht immer korrekt übernommen.

Beispiel CSV-Importdatei


Resultat als CSV-Export


Ich habe das verwendete Import-Profil zum Reproduzieren mit angehängt. Den Import starte ich über Start -> Hibiscus -> Bank Accounts -> Rechtsklick auf Kontoeintrag -> Umsätze Importieren...

Ich verwende jameica 2.8.6 + Hibiscus 2.8.24 auf einem Windows 10 Rechner.

Du verwendest scheinbar ein englisches Locale. Dabei kommt es bei den Beträgen zu einem Problem mit den Dezimaltrennern. Das Thema hatten wir erst kürzlich unter forum/topic.php?p=156151#real156151

Das hatte ich bereits gesehen. Das "behebt" zwar das Problem mit den abgeschnittenen Centbeträgen. Die fehlerhafte Verwendungszweck-Zuordnung ist aber weiterhin vorhanden.

Da werden die Verwendungszwecke scheinbar auf 27 Zeichen Länge neu umgebrochen. Das war bisher das Standard-Format für Verwendungszweck-Zeilen (MT940). X Zeilen a 27 Zeichen. Jetzt mit CAMT gibt es nur noch 1 Zeile a 140 Zeichen. Aufgrund der Tatsache, dass immer noch - wahrschenlich nicht wenige - Banken die Umsätze im alten Format liefern, werden die Verwendungszwecke an verschiedenen Stellen neu umgebrochen. Zum Beispiel auch wenn man eine Überweisung an eine Bank sendet und diese dann als Umsatzbuchung wieder von der Bank abruft, wenn die Bank hier noch das alte Format verwendet.
Wie sieht denn der Verwendungszweck direkt im Programm aus und wie sieht er aus, wenn du den Umsatz in einem anderen Dateiformat exportierst - z.Bsp. im Hibiscus-XML-Format?

Siehe angehängte Dateien. Also die Auftrennung macht so keinen Sinn und wird beim Onlineabgleich übrigens auch nicht so geliefert.

Das macht schon Sinn. Gezwungenermaßen. Wie schon erwähnt haben wir derzeit in Deutschland eine Misch-Situation von Umsätzen mit mehreren Zeilen a 27 Zeichen und einzelner Zeilen mit 140 Zeichen. Nicht nur im Bankingprogramm kommt es hierbei zwangsweise zum Umbrechen von Zeilen. Auch bei den Banken selbst. Hibiscus hat beim Import noch ein paar Zeichen Extra-Toleranz. Konkret 35. Wenn eine Zeile Verwendungszweck beim CSV-Import länger als 35 Zeichen ist, bricht Hibiscus die Verwendungszwecke neu um, damit die Einzelzeilen unterhalb des Limits bleiben. Daher: Passe die CSV-Datei so an, dass keine Zeile mehr als 35 Zeichen hat. Dann übernimmt Hibiscus die Zeilen 1:1.

Das Thema mit den Verwendungszwecken hatten wir hier im Forum schon oft. Es ist ein leidiges Thema.

Ich verstehe, dass Spalten länger als 35 Zeichen neu umgebrochen werden müssen (intern, in der DB wenn ich es richtig verstehe?), aber ich halte es für grundsätzlich falsch, wenn Zeichen beim Umbrechen von der zweck2-Spalte z.B. plötzlich in die zweck-Spalte rüberwandern. Das widerspricht einem klar separierten Format wie CSV doch völlig?


wird zu


Wenn technisch (DB-mäßig?) nur die zweck3-Spalte mehrzeilig sein darf, dann würde ich wenigstens erwarten, dass die überschüssigen Zeichen aus zweck2 in die zweck3 Spalte wandern. Optimal wäre natürlich eine mehrzeilige zweck2 Spalte.
Beim neu Umbrechen wäre es auch sinnvoll, bei bereits vorhandenen Leerzeichen umzubrechen, um den Text nicht noch weiter zu verhackstückeln.

Kann ich über den CSV-Import irgendwie steuern, wo umgebrochen wird (\n oder ähnliches)?



wird leider folgendermaßen umgebrochen



Als Vergleich hier mal noch ein online von der Bank übertragener Verwendungszweck für diese monatliche Transaktion.

Ich hab das Neu-Umbrechen der Zeilen beim CSV-Import von Umsätzen jetzt mal komplett entfernt. Ist morgen im Nightly-Build. Die Zeilen sollten jetzt genauso übernommen werden, wie sie in der CSV-Datei stehen. In der Zweck 3 wird es aber nach wie vor zu Umbrüchen kommen. Versuche daher nach Möglichkeit alles in Zweck 1 zu packen.

Danke, ich habe es gerade ausprobiert und das Ergebnis sieht nun deutlich besser aus!

Zur Info: Spalte zweck1 kann max. 255 Zeichen enthalten, Spalte zweck2 max. 35. Alles darüber führt zu Importfehlern. Spalte zweck3 wird momentan immer noch fest nach 35 Zeichen getrennt (keine Rücksicht auf Trennung von Zeichenketten).