Drucken/Export: Gegenkontotext in Verwendungszweckspalte

Wie wird es denn direkt in Hibiscus angezeigt? Oder beim Export im HTML-Format? Ist es da auch verrutscht?

Kann es sein, dass das von der comdirekt oder SPARDA stammt?

bitte mal Update machen - 2018-06-27 Jameica 2.8.0 Hibiscus 2.8.3
(die installierte Software datiert vom 2017-07-11 bzw. 20170627)

Was wird denn als "roher" Verwendungszweck angezeigt, wenn du die Buchung in Hibiscus durch Doppelklick oeffnest, um die Detailansicht zu oeffnen und dort die Option "Alle Daten des Verwendungszwecks anzeigen?

ich vermute, da steht dann sowas in der Art:



Falls dem so ist, kann ich das in Hibiscus nicht ändern. Es gibt Banken, die verwenden zwar die SEPA-Tags "ABWA", "KREF", etc., fügen den eigentlichen Verwendungszweck dann aber einfach ohne explizite Angabe von "SVWZ+" ein. Daher enthält Hibiscus hier eine Sonderbehandlung. Wenn der Verwendungszweck SEPA-Tags enthält, jedoch KEIN "SVWZ", dann wird die Zeile als Verwendungszweck verwendet, die kein Tag enthält. Würde ich das Verhalten ändern und damit deinen Fall korrigieren, würde ich damit das Parsen des Verwendungszwecks bei anderen Banken wieder kaputt machen, weil sich hier zwei unterschiedliche Interpretationsarten überschneiden.

Siehe Anhang.



Na großartig

Kann ich interessehalber die komplette HBCI Kommunikation mitloggen lassen in eine Datei?
Sind in Hibiscus Sonderbehandlungen für Banken als Plugin o.Ä. vorgesehen für HBCI (ich weiß von den Scrapern für zB DKB Visa, aber das wäre ja anders denke ich)?
Ich habe nicht groß geschaut, da nicht viel Zeit, aber passiert das ganze Parsen von HBCI in hbci4java und hibiscus bekommt dann nur die schon fertigen Felder wie "Betrag", "Vzweck" übergeben? Also falls ich es für mich für die Sparda anpassen wollen würde, müsste ich hbci4java umschreiben?

Gerade bei SPARDA hast Du keine Chance, irgendwas anzupassen, weil man nie weiß, wie es kommt. Das ist leider nicht immer gleich. Hängt von der Art des Geschäftsvorfalles und auch von der Form der Daten ab, die die gegnerische Bank (bei Zahlungseingängen) liefert (mit Leerzeichen dazwischen oder nicht usw.). Solange Sparda HBCI so behandelt wie derzeit und vor allem auch das alte "deutsche" vor-SEPA-Format MT940 für die Übertragung der Umsätze verwendet, hast Du keine Chance. Allerdings würde ich auch nicht glauben, dass die in absehbarer Zeit auf das neue CAMT-Format übergehen. Die machen nichts an Ihre HBCI-System, solange es nicht unbedingt sein muß. Ist vielleicht auch besser so, denn wenn sie bisher irgendwas geändert haben, war das immer ein monatelanges Gezerre, bis das halbwegs gelaufen ist (und zwar nicht auf Testsystemen sondern im echten Onlinebanking).

Fazit: Keine Chance, selbst etwas zu machen. Wenn Du auf "anständige" Feldbelegungen angewiesen bist, hilft nur ein Bankwechsel.

Kurz und knapp das Format MT940 erklärt:

:xx: sind Hauptfeldschlüssel, dabei ist :86: der Feldschlüssel für Verwendungszweck.

?xx sind Unter-Feldschlüssel in einem :xx:-Feld. Dabei sind ?20 bis ?29 Unter-Feldschlüssel für "reine Textzeilen". Darüberhinaus gibt es noch andere für Empfängername, Kontonummer, BLZ usw.
Sparda verwendet ausschließlich reine Textzeilen. Das, was im Onlinebanking angezeigt wird, wird einfach aneinandergefügt und dann mit dem großen Vorschlaghammer in die ?xx Texteilen "eingepaßt". Die Textfelder sind 27 Stellen lang (altes Maß vom alten Inlandszahlungverkehr), somit kommen immer 27 Stellen rein und dann geht es ins nächste Feld. Nachdem die Textzeilen im SEPA-Format andere Längen haben.... paßt das dann natürlich nicht. So kommt dann irgendwo mitten in einem Wort eine neue Zeile - deswegen das ?xx mitten im Wort.

Die + sind Sonderfeldschlüssel, die definiert sind, um SEPA-Felder übergangsweise im alten MT940-Format unterzubringen. SWVZ+....... ist die Feldkennung für Verwendungszweck. MREF+ der für die Referenznummer usw. Normalerweise müßte der SEPA-Feldschlüssel IMMER auf der ersten Stelle einer ?xx-Zeile stehen und dann der Feldwert SOFORT nach dem + kommen und nach Ende des Feldwertes der Rest der ?xx-Zeile leer bleiben. Neuer SEPA-Feldschlüssel dann auf einer neuen Zeile beginnend. Sparda ignoriert das alles. Die beginnen die SEPA-Feldschlüssel IRGENDWO, machen nach dem + noch ein Leerzeichen und dann nach Ende des Feldwertes wieder ein Leerzeichen und dann direkt anschließend den nächsten Feldschlüssel usw. Es gibt Kundenprogramme, die die Texte aus einem sinnvoll belgten MT940-Satz mit SEPA-Unterfeldschlüsseln aufarbeiten und in der lokalen Datenbank in entsprechende Felder packen. Aber dazu müssen diese Felder so belegt sein, wie es spezifiziert ist - und das ist bei Sparda absolut nicht der Fall und auch nicht weiter nachvollziehbar.

Geht schon in der ersten Zeile los: Name des Zahlungsgegners lt. SEPA sind 2mal 40 Stellen lang. Sparda verhackt das in 27stellige (altes Maß) Felder, deswegen ist nach ...GRUP erst mal Schluß, danach setzen die ein Komma und ein Leerzeichen (willkürlich), dann kommt der rest PE. Dann wieder Leerzeichen und Vorgangsart, dann sollte der Feldschlüssel SVWZ+ kommen - hier schlägt aber wieder das Zeilenende der 27er Zeile zu, deswegen wird SV WZ+ daraus, dann das nicht spezifiezierte Leerzeichen nach dem + dann der Verwendungszweck, wie ihn die gegnerische Bank liefert, aber wieder nur der Rest der Zeile aufgefüllt bis ...HAFTP und ein Leerzeichen willkürlich und dann weiter mit dem Verwendungszweck. So geht es dann weiter. Kraut und Rüben halt.