DTA-Datei unverändert übertragen

Hi Chris,

ähm, die VR-NetWorld Software fasst die DTA Datei, soweit ich weiß, bei der Option "zur Übertragung einlesen" nicht an. Woran machst Du den fest, dass die VRNWS bzw. SM die Daten anfasst?

Gruß

Holger

Hallo,

das stimmt nicht ganz. Die DTAUS-Datei wird in HBCI als transparenter binärer "BLOB" und nicht als Datensätze übertragen und sollte deshalb unverändert bei der Bank ankommen. Es kann höchstens sein, dass Bankseitig eine über HBCI empfangene DTAUS-Datei anders als eine über anderem Wege erhaltene DTAUS-Datei verarbeitet wird.

Noch zur ursprünglichen Frage: Um nur eine DTAUS Datei per HBCI hochzuladen könntest Du mein FinCmd (Teil der Subsembly FinTS Tools) verwenden. Ist für private Nutzung kostenlos.

Hi Frank,

ich vermute es so ähnlich wie Du. Daher die nachfrage.

Gruß

Holger

Öhm, nö, da sagt die HBCI-Spezifikation (z.B. die 3.0, S. 97 Sammellastschrift HKLSA) das Gegenteil.

Aber, ...



... das hier ist auch eine Lösung, die ich mir bei Gelegenheit mal ansehen werde, da noch andere Features (die verteilten Unterschriften) für uns evtl. ganz interessant sind (wenn auch nicht absolut zwingend).

Danke!

Grüße,

Chris

Fellini hat hier völlig recht.
Der DTAUS Spezifikation nach sind keine Umlaute erlaubt (ich schätze du meinst den HBCI-Zeichensatz, der gilt hier bei Sammlern aber nicht).
Bei einer Datei mit Umlauten wird genau anhand der DTA-Spezifikation gewandelt oder im Extremfall die Datei sogar verworfen. Umwandlung ist nur in Leerzeichen oder Punkte erlaubt.

Was meinst du mit Kundennummern? An welcher Stelle im C-Satz?

Hallo,



Ja, prima Sache, das FinCmd. Hab ich eben mal ausprobiert. Toll, danke.

Eine Frage noch dazu: Ich muss da in der Kommandozeile mit "-pin irgendwas" meine Karten-PIN angeben. Dabei würd ich die soviel lieber über den Kartenleser eingeben. In Subsembly FinTS Admin geht das (beim Bankkontakt synchronisieren fragt der Kartenleser direkt nach der PIN). Gibt's da einen Trick, das Kommandozeilen-Tool auch zur PIN-Abfrage per Kartenleser zu bringen? Oder übersehe ich etwas Offensichtliches?

Vielen Dank,

Grüße,

Chris

Leider falsch, wie weiter oben schon angemerkt. DTAUS kann Umlaute in ganz spezieller DTAUS-Codierung, aber keine Kleinbuchstaben.

SEPA hingegen kann Kleinbuchstaben aber KEINE Umlaute. Siehe EBICS Anlage 3 Seite 26.

Ebenso werden von beiden Formaten verschiedene Mengen an Sonderzeichen unterstützt.

Um die Sache noch etwas konfuser zu machen. Im MT-940 Kontoauszug dürften eigentlich auch keine Umlaute vorkommen und die Menge der erlaubten Sonderzeichen ist hier schon wieder eine andere.

Da sprichst Du etwas Wichtiges an ...



Jaaa. Genau. Es ist mehr als seltsam.

Ich muss mich an dieser Stelle mal als Fan deutscher Umlaute outen - und als jemand, der sehr regelmäßig Umlaute im Kontoauszug vorfindet (und sich freut, dass es Banken gibt, die die vernünftig mit übertragen). "Ausbleibende" Umlaute in Form von Leerzeichen sehe ich hingegen sehr selten.

Ich wünsche mir einfach - ich muss das einfach mal loswerden - dass im Rahmen der europäischen Vereinheitlichung, Einigung, Euro usw. usf. - was ich alles im Grunde auch total toll finde - auch die Bankenwelt die Gelegenheit beim Schopfe ergreift, den Zeichensatz für zukünftige Geschichten (ich denke hier an allererster Stelle an SEPA) *bitte* etwas auszuweiten.

Man sieht ja an den verschiedenen Betriebssystemen die es so gibt (ich sag nur Unicode), an den Internet-Domainnamen (Internationalized Domain Names), an E-Mail- und Webseiten-Inhalten, wohin technisch die Reise geht. Und während man sich "in der Welt da draußen" mit ganz bizarren Problemen beschäftigen muss (was z.B., wenn es Webseiten gibt, deren URL man nichtmal eintippen kann, weil man einfach nicht weiß, wie man chinesischen Text irgendwo abschreibt und eintippt? ;-)), ist Europa groß, aber nicht *soo* groß, dass es nicht machbar wäre, zumindest viel mehr "romanische" Zeichen (also ohne griechische und kyrillische) in den Zeichensatz aufzunehmen.

Ich möcht hiermit also ein Lanze für Sonderzeichen brechen. Wer auch immer Einfluss hat in dieser Richtung und hier versehentlich mitliest ;-) - bitte immer wieder das Thema ansprechen. Das ist sicherlich nix, was von heute auf morgen kommt - das kann viele Jahre dauern.

Aber ich hoffe sehr darauf! Schließlich sind wir hier im Europa der Vielfalt und nicht im ASCII-Land, und das ist auch schön so. :)

Viele Grüße (nicht Gruesse!),

Chris

(der - zum Glück - keinen Namen mit Sonderzeichen hat und aus keiner Stadt kommt, die sich je nach Zeichenvorrat anders schreibt. aber sowas soll's ja häufig geben! :-))

P.S.: Ich bitte potentiell stirnrunzelnde Moderatoren um Nachsicht. Musste einfach mein kleines Plädoyer loswerden, und ich glaub, hier am Ende vom Thread stört's auch nicht wirklich. Danke. :)

Warum Stirnrunzeln? Du hast ja Recht. Ich arbeite im Zahlungsverkehr einer Sparkasse und darf mich solchen und ähnlichen Kundenanfragen viel zu oft herumschlagen. Ich hab aber selten Kunden am Rohr, die das Tehma so sachlich und gut informiert angehen. Vielen Dank auch für die kleine Zeichensatzkunde. So kompakt hatte ich die noch nie auf einem Haufen.

Die gemischte Groß- und Kleinschreibung kannst du übrigens bei SEPA-Eingängen auf deinem Konto bewundern.

CU
Frank

Auch wenn du dich gerade als Genosse gepoutet hast - intern können die Bankrechenzentren heute deutlich mehr. Man glaubt es nicht, aber die gehen auch mit der Zeit. Extern müssen halt weiterhin die geltenden Standards beachtet werden. Und die werden von Politikern gemacht. Die Ergebnisse haben wir hier ja ausgiebig diskutiert. Noch ein kleines Highlight am Rande: Bei der Konzeption wurden die Buchungstextschlüssel schlicht vergessen. Die Politiker meinten, dass es reicht, wenn ein Zahlung beim Empfänger ankommt. Schade nur, dass in Deutschland z.-b. die VL explizit über Textschlüssel gekennzeichnet werden muss - ohne wirds nix mit Sparzulage. Das wird jetzt nachgebessert.

CU
Frank

ps: Ne Öscher *freu* Kommst du an Karten für die Alemannia? Ich würd gern nochmal den alten (und einzig wahren) Tivoli genießen.