Hallo!
Ich bin begeistert, wie sehr Hibiscus die Fereins-Finanzen erleichtert!

Bei Export der Umsätze entsteht leider folgendes Problem:
Der Export enthält In der Zeile "Verwendungszweck" Verkettungen aus dem eigentlichen Verwendungszweck UND IBAN, Bic, teilweise Gegenkontoinhaber u.v.m.
Der Export enthält also alle von mir benötigten Informationen in den entsprechenden Zeilen, aber zusätzlich sind manche dieser Infos an den jeweiligen Verwendungszweck hinten drangehängt. Das ist sehr unübersichtlich.
Das Problem besteht bei Export als CSV, HTML und PDF. (SWIFT und Hibiscus-Format konnte ich nicht öffnen...)
Gibt es eine Lösung für das Problem?
Gruß und Dank, Hannes.

(Ich nutze Hibiscus 2.10.4, das Bankkonto befindet sich bei der GLS-Bank, mein Betriebssystem ist MacOS 12.1)

Warum schreibst Du das im Forum "Allgemein" und nicht im hibiscus-Forum, wo es doch um hibiscus geht?

Zur Sache:
WItzigerweise ist das aber sogar ein "allgemeines" Problem. Der VZ wird - auch in hibiscus - so eingestellt, wie die Bank ihn liefert. Das heißt, das ist nicht ein Problem von hibiscus sondern ein Problem des Bank-Rechenzentrums. Die liefern einen Text, der 1:1 ins entsprechende hibiscus-Feld eingestellt wird. hibiscus kann daran nichts ändern. Ist bei anderen Programmen genau so.

Hntergrund dazu ist, dass viele Banken bis heute noch nicht den kompletten Umstieg zu den SEPA-Formaten geschafft haben. Div. Feldinhalte, für die es im SEPA-Datensatz eigene Felder gäbe, werden nach wie vor einfach in den Verwendungszweck geschrieben. Nachdem Du von IBAN und BIC usw. schreibst, lass mich raten, es handelt sich um ein Konto aus dem Volksbanken/Raiffeisenbanken-Bereich? Stop, ich sehe gerade, GLS-Bank... damit treffe ich aber trotzdem in's Schwarze, da die GLS bei ATRUVIA (dem Rechenzentrum der VR-Banken) rechnen läßt. Dass diese Inhalte schon vom RZ in den Verwendungszweck geballert werden, kannst Du übrigens auch im WebBanking sehen, da steht das auch alles schon im VZ.

Wie msa schon schrieb - die Bank liefert die Daten halt so.

Hibiscus kann aber versuchen, den eigentlichen Verwendungszweck aus diesem gemischten Feld zu extrahieren und dann nur diesen Text-Teil anzeigen. Klicke hierzu links in der Navigation auf "Umsätze" und dann oben rechts auf das Werkzeug-Symbol (links neben dem grünen Zurück-Pfeil). Dort gibt es eine Option "[x] Alle Daten des Verwendungszwecks anzeigen". Deaktiviere diese Option. Versuche dann den Export nochmal. Im CSV- und PDF-Export sollte dann nur der Teil aus dem Text exportiert werden, der der eigentliche Verwendungszweck ist. Aber nur, insofern Hibiscus bei den Buchungen in der Lage ist, das korrekt aus dem Text zu extrahieren. Nicht bei allen Buchungen klappt das vernünftig.
Der HTML-Export wird grundsätzlich mit allen Daten exportiert.

Darüber hinaus: Wenn deine Bank es unterstützt, könntest du versuchen, den Umsatzabruf auf CAMT umzustellen. Siehe https://www.willuhn.de/wiki/do…ormat_camt
Das ist das neue SEPA-taugliche Format für den Umsatzabruf. Wenn du Glück hast, liefert die Bank darüber dann "saubere" Verwendungszweck-Zeilen. Das gilt dann aber nur für die ab der Umstellung neu abgerufenen Umsätze.

Vielen Dank!
Das ist ja ein furtbares Durcheinander, das die Banken da liefern!
Wenn ich das Online-Banking der GLS nutze, sind nicht so viele Infos in einer Spalte.
Wahrscheinlich wird das einfach nach einer gewissen Zeichenzahl abgeschnitten. Ohjeohje...
Die GLS scheint CAMT standardmäßig nicht zu unterstützen, aber vielleicht im Rahmen eines Business-Zugangs:
https://vrkennung.de/systemwec…ftsbanken/
Ich bleibe also dran. Gruß und Dank! H.

Hallo, da brauchst Du Dir keine "unnötigen Umstände" machen, Dein Problem ist (derzeit) nicht lösbar. Der genannte Systemwechsel vom ehemaligen GAD-System zum neuen gemeinschaftlichen System von GAD+Fiducia = ATRUVIA ist erfolgt. Dieses neue System liefert über alle Kanäle die gleichen Daten aus, egal ob WebBanking PrivateEdition, WebBanking BusinessEdition oder HBCI. Die Daten via HBCI werden übrigens via CAMT geliefert, aber die Felder im CAMT-Datensatz sind eben so belegt wie sie sind. Daran ist übrigens noch nicht mal das RZ direkt schuld, das ist die Gesamtgemengelage. Es gibt Banken, die arbeiten mit den alten nationalen Feldern (eine Zeile VZ ist 27 Zeichen lang und SEPA-Neufelder werden mit in den VZ gepackt), es gibt Banken, die arbeiten mit den neuen SEPA-Feldern (VZ ist 35 Zeichen lang). Bei der Datenübergabe von einer Bank zur anderen wird dann also munter konvertiert. Bei 35 -> 27 wird also stets nach 27 Stellen eine neue Zeile begonnen, egal was dabei herauskommt. Bei 27 -> 35 wird die Zeile vollgemacht, neue Zeilen werden einfach angeklebt, mal mit mal ohne einem eingefügten Leerzeichen. Ganz wie die jeweilige Bank das programmiert hat. Was dann am Ende rauskommt ist das von Dir bemängelte Durcheinander. Bei ATRUVIA kommt noch hinzu, dass man IBAN und BIC zusätzlich mit in den VZ packt, da man wohl davon ausgeht, dass noch nicht alle Weiterverarbeitungsprogramme die neuen gesonderten Felder IBAN und BIC verarbeiten. Du musst also bis auf Weiteres mit dem leben, was Du derzeit hast.

Eine maschinelle Weiterarbeitung ist eigentlich nur möglich, indem man den VZ nimmt, alle Zeilenvorschübe und Leerzeichen rausfiltert und diesen String dann zugrunde legt und darin etwas sucht. Alles Andere ist zum Scheitern verurteilt, weil wie gesagt durch Konversionen mitten in Wörtern oder Nummern eingefügte Leerzeichen stehen können und dann nichts mehr gefunden wird.

Ohgottohgott.
Vielen Dank für die Infos, dann kann ich mir das wirklich sparen und muss mit den unübersichtlichen Verwendungszwecken leben...
Gruß und Dank! Hannes.

Hallo msa,

im Fall der Atruvia liegst Du in deiner Interpretation meilenweit daneben.
Der Aufbau und der Inhalt der Umsatzinformationen im Onlinebanking, FinTS und EBIICS sind keineswegs identisch (die Unterschiede liegen im Detail.)
Dann muss man unterscheiden zwischen den Informationen, die maschinenlesbar sind und die die für den Menschen zum Lesen gedacht sind.

Im alten Format MT940 werden diese SEPA Informationen (Ende-zu-Ende-Referenz, Abweichender Auftraggeber usw.) in den technischen Verwendungszweck geschrieben und mit vorgegebenen Tags gekennzeichnet. Der eigentliche für den Anwender lesbare Verwenungszweck wird ebenfalls als solcher gekennzeichnet und enthält alles was aus Sicht des RZs für den Anwender von Interesse sein könnte.

Im camt, stehen alle diese Informationen in den im camt vorgesehenen Feldern und können so maschinell ausgelesen werden.Sprich Sepa Informationen in den dazugehörenden XML Feldern und der Verwendungszweck für den Anwender in dem entsprechenden Feld für den Verwendungszweck - ohne weitere technische Krücken für die maschinelle Lesbarkeit.

Der eigentliche Verwendungszweck enthält neben dem Verwendungszweck aus dem eigentlichen Zahlvorgang weitere Informationen in einer für den Menschen lesbaren Form. Diese sind zum Teil identisch mit den Informationen , die in den maschninell auslesbaren Feldern stehen. So steht - wenn vorhanden auch der abweichende Auftraggeber im Verwendungszweck und ist so direkt erkennbar, egal, ob eine Anwendung das beherrscht oder nicht.
Da diese Informationen alle mit einem an den Bezeichnern aus dem MT940 angelegten Kennzeichen eingestellt sind, könnte man diese sogar tatsächlich rausfiltern.

Ich bewerte nicht, ob das Vorgehen gut/schlecht, sinnvoll, hilfreich oder Nonsens ist. Aber das Vorgehen ist technisch durchaus sauber und es ist eine Frage der Philosophie, ob man diese Informationen jedem lesbar zugänglich machen möchte.
Andere Banken machen das Gegenteil, nehmen solche Informationen ganz raus, weil Sie der Meinung sind, dass das datenschutzrechtlich bedenklich wäre.

Das kann man alles gut oder schlecht finden, aber es ist zu mindestens technisch alles so sauber, dass man für eine Verarbeitung der Daten keine Sonderlocken bauen muss. Im Fall der Atruvia sogar so sauber, dass man hier eine Sonderlocke bauen kann, wenn man diese Daten anderweitig auslesen und anzeigen möchte.

Hallo Holger,

ich habe soweit ich weiß nichts von EBICS geschrieben, sondern mich nur auf Web (Privat+Business) und HBCI bezogen. Dass über EBICS etwas anders Aufbereitetes kommen kann, davon gehe ich aus. Ich habe aber ausdrücklich nichts davon geschrieben, weil ich mit ATRUVIA-EBICS keine Erfahrungen habe und keine darüber eingelesenen Daten kenne - also kann und darf ich darüber nichts schreiben

Ich stimme Dir zu, dass ATRUVIA-Verwendungszwecke "halbwegs sauber" sind. Trotzdem geht mir persönlich die Einstellung von IBAN, BIC und weiteren Feldern im Verwendungszweck auf die Nerven. Verwendungszweck ist Verwendungszweck und nicht "alles was man vielleicht anschauen möchte"... aber das ist Ansichtssache. Wenn man das konsequent zu Ende denken würde, dann müsste der Zahlungsgegner ja dann eigentlich auch mit in den Verwendungszweck rein, denn den will man ja auch anschauen? Und was ist mit Buchungsdatum und Wertstellung? Auch das will man ggf. sehen... Ich habe es mir gerade nochmal angeschaut und mich etwas gewundert, bei den meisten Buchungen ist im Verwendungszweck die IBAN & BIC als Wiederholung mit drin - bei manchen aber NICHT. Einen Sinn kann ich dabei nicht erkennen. Speziell fand ich gerade, dass die Angaben für "fremde Zahlungen" soweit ich sehe immer drin sind, bei "eigenen" Zahlungen (hier von einem eigenen Konto bei VR-Bank A auf ein eigenes Konto bei VR-Bank B) aber fehlen. Sehr komisch. Im alten WebBanking sind die Felder Kontonummer und BLZ während der SEPA-Umstellung irgendwann rausgefallen, IBAN und BIC nie dazugekommen. Immerhin, im unsäglichen neuen WebBanking sind sie jetzt wieder korrekt drin - da stört nur noch die Wiederholung im VZ

Ansonsten - ja, die Daten als CAMT über HBCI sind gut belegt - da stört mich aber die Wiederholung von div. Feldern im VZ sehr, weil es den VZ massiv aufbläst und die ganze Buchung damit sehr viel unübersichtlicher macht. Die Philosophie, für alle Kunden VZ der Buchungen mit allen möglichen Feldwiederholungen aufzublasen, weil es ja irgendwelche Programme geben könnte, die die korrekten Felder vielleicht nicht anzeigen, halte ich für fragwürdig. Aber das ist natürlich Ansichtssache.

Und was die "zerklüfteten" Verwendungszwecke, bei denen "Original-Zeilenenden" verlorengegangen sind, willkürliche Zeilenenden und Leerzeichen eingefügt wurden usw. - dass da jeweils die einzelne Bank nichts dazu kann ist klar. Das hätte man nur vermeiden können, wenn man wie beim Zahlungsverkehr die alten Feldformate zu einem Stichtag verboten hätte. Mir erschloss sich eh nicht, wieso die Verwendung von DTAUS zur Konvertierung bei der Bank explizit verboten wurde, die Auslieferung von Umsätzen via MT940 aber bis heute erlaubt und vielfach geübte Praxis ist. Mit allen Konvertierungen hin und her zwischen verschiedenen Instituten/Systemen.