Hallo,

gibt es eine Software, die DTA-Dateien, die man ihr vorsetzt, unverändert / weitgehend ungeparst direkt per HBCI zur Bank hochladen kann? Also wenn's eine DTA-Datei voller Lastschriften ist, einfach in ein HKSLA-Segment steckt, und fertig?

Ich hätte gern, dass so Dinge wie Kundennummer (pro C-Datensatz), Referenznummer (A-Datensatz) oder ähnliches, was unsere Software hier vor Ort in die DTA-Datei mit hineinschreibt, nicht angefasst und verändert werden, was z.B. StarMoney oder VRNetWorld leider machen. (Letzteres kennt immerhin schonmal Referenznummern - die kennt StarMoney scheinbar nicht.)

Zumal ich denke: Wenn man seine DTA-Datei statt HBCI im Web-Banking hochlädt, geht das ja (und die von unserer eigenen Software erstellte DTA wird so auch brav von der Bank-Software angenommen) - aber HBCI mit Chipkarte ist mir lieber als Web-Browser, also hoffe ich, dass es auch Software gibt, die einen direkten, unveränderten DTA-Upload darüber durchführen kann.

Irgendwelche Tips? Gibt doch bestimmt Software-Autoren hier, die wissen, wie ihre Software sich verhält. :-)

Dankeschön!

Chris

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

per HBCI werden nur DAtensätze, keine ganzen Dateien übertragen. Daher werden über diesen Kanal die Datensätze immer angefasst werden müssen.

Die Lösung ist der FTAM/EBICS- "Kanal". Hier kannst du die DTA- Dateien komplett übertagen. Die dazugehörige Software haben fast alle Banken auch in ihrer Produktpalette, du wirst also sicher bei deiner Bank was finden.

Tschau
Majo

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.

Ich hab bezüglich der Veränderungen eher die Banken im Verdacht. Nicht jede gibt auch weiter, was der Kunde da reinschreibt. Wenns die Software aber schon vorher rauswirft, kann die Bank natürlich nichts machen.

CU
Frank

Hi Frank,

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

Gruß

Holger

Hi, das hab ich auch gedacht. :-) Macht sie aber leider doch - die Datei wird anscheinend geparst, und z.B. werden die Umlaute in AE, OE, UE, SS gewandelt (obwohl nach DTA-Spezifikation zulässig), und die Kundennummern (pro C-Datensatz) gehen scheinbar auch verschwunden.

In der Tat, die Funktion "zur Übertragung einlesen" klingt ja auch wirklich so, als würde die die Datei ganz unverändert übertragen, aber da ist anscheinend doch noch ein Verarbeitungsschritt zwischendurch.

Edit, zur Klarstellung: Man sieht nach "zur Übertragung einlesen" schon im Ausgangskorb Änderungen ggü. dem ursprünglichen DTA-File. Ich könnt jetzt noch in's technische Log schauen, ob man bei der Übertragung an sich auch noch Änderungen im DTA-File ggü. der ursprünglichen Version sieht, aber ich denke, schon.


Grüße,

Chris

Ö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

Chris, der DTAUS-Datensatz kennt keine Umlaute. Wenn die Software die nicht ändern würde, dann hättest du Leerstellen anstelle der Umlaute im VWZ.
Wenn Du den vollen ASCII haben willst, dann musst du SEPA-Überweisungen machen. Ab November 2009 wird es dann auch Lastschriften geben. Aber Vorsicht. Da kommt anstelle der Einzugsermächtigung das Mandat. Da kommt einiges an Umstellungsaufwand auf alle zu, die Lastschriften einziehen. Dafür aber auch einige Vorteile für beide Seiten.

CU
Frank

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?

Hmmm, dann hab ich vielleicht eine andere DTAUS-Spezifikation ...

In meiner steht drin: "Zeichencode
Zugelassen sind
• die numerischen Zeichen 0 bis 9 (X’30’ - X’39’)
• die Großbuchstaben A - Z (X’41’ - X’5A’)
• die Sonderzeichen
Leerzeichen „ „ = X’20’
Punkt „.“ = X’2E’
Komma „,“ = X’2C’
Kaufmännisch „und“ „&“ = X’26’
Trennstrich „-„ = X’2D’
Plus-Zeichen „+“ = X’2B’
Stern „*“ = X’2A’
Prozent-Zeichen „%“ = X’25’
Schrägstrich „/“ = X’2F’
Dollar „$“ = X’24’
• sowie die Umlaute Ä, Ö, Ü und das ß. Hierfür gelten die Codierungen „Ä“ = X’5B’,
„Ö“ = X’5C’, „Ü“ = X’5D’, „ß“ = X’7E’.
"

Falls es da eine andere / richtigere / neuere / was-auch-immer gibt, wäre ich für einen Pointer dankbar. Dass es bei DTAUS keine Umlaute gibt, wär mir völlig neu, aber lass mich gern eines besseren belehren.

Dankeschön!

Viele Grüße,

Chris

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

Ah, ich überlas. Feld 6. "interne Kundennummer"


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.

Nein, Du übersiehst nichts. Das Tool ist für einen automatisierte Aufruf und nicht für die interaktive Nutzung gedacht. Deshalb muss die PIN immer gleich mitübergeben werden.

Für die interaktive Nutzung habe ich aber auch etwas auf meiner Homepage

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. :)

(Ich muss übrigens demnächst mal auf meinen Kontoauszügen schauen, ob ich irgendwo einen Überweisungseingang finde, wo Groß-/Kleinschreibung und Umlaute kombiniert auftreten. Das wäre dann ein echtes Faszinosum. ;-))

Kleiner Exkurs am Rande: Diese Kodierung ist gar nicht so speziell. In der guten(?) alten Zeit, wo Zeichensätze noch 128 Zeichen umfassten und mit 7 Bit codiert waren, hatte man sich in Europa überlegt, ob man da noch irgendwo Sonderzeichen reinpfuschen konnte. Zehn Jahre nach ASCII, also ca. Mitte der 1970er Jahre, war's dann so weit, und es entstand DAS GRAUEN(TM), das heute DIN 66003 heißt (http://de.wikipedia.org/wiki/DIN_66003), anderswo auch zusammenfassend als ISO 646 bekannt. Technisch ging's damals sicherlich nicht wirklich besser, dafür war Speicherplatz noch viel zu teuer.

Mitte der 1980er war dann schon ISO 8859 am Start, wo man ja mit 8 Bit pro Zeichen arbeitet, und wo folglich für Sonderzeichen für damalige Verhältnisse geradezu luxuriös viel Platz verfügbar war. Jenseits vom großen Teich (DOS) bohrte man damals seinerseits das 7-Bit-ASCII mit grafischen Sonderzeichen auf, und unterschiedliche "Codepages" gab's auch irgendwann - CP437 und CP850 sagt sicherlich so manchem noch etwas. ISO 8859-1 hat sich auf dem Massenmarkt dann auch erst durchsetzen können, als Microsoft mit Windows 95 und Verwandten darauf umschwenkte (und die Codepages, die wohl eher aus der IBM-Ecke kamen, fallenließ).

Das zeigt auch, aus welcher Zeit das DTAUS-Format wohl stammen muss: Es verwendet mit seiner (zumal eingeschränkten) Variante von ISO 646 eine Zeichencodierung, die Mitte der 1980er schon wieder obsolet war ...

Lustig übrigens, dass *der* Zeichen-Standard heute ISO 10646 heißt (quasi identisch mit Unicode) - die Bezeichnung ist sicher kein Zufall. Was zeigt, dass Standardisierungsorganisationen auch so ein bißchen was wie (gemeinen?) Humor haben.


Gute Nacht zusammen, :-)

Chris

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

Danke. Gern. :)

Ich hab irgendwann mal letztes Jahr angefangen, das Software-Modul, das in unserer Vereins-Software DTAUS-Dateien erzeugt, um Mitgliedsbeiträge per Lastschrift einziehen zu können, zu überarbeiten.

War ziemlich grausiger PHP-Code, und ziemlich fehlerhaft. Jetzt ist's immer noch ziemlich grausiger PHP-Code (und ich weiß nicht, ob das mehr an PHP oder an mir liegt), aber es funktioniert nun deutlich besser.

Dabei lernt man so einige seltsame Sachen und bekommt einen schönen Blick in die EDV-Vergangenheit (die für mich z.T. auch schonmal Gegenwart war, auch wenn ich damals noch "klein" war :-)).

Ich hab in dem Zusammenhang auch angefangen, mich sehr für SEPA zu interessieren. XML ist zwar auch wieder was Seltsames, aber es macht schon alles einen sehr viel frischeren Eindruck als dieses 1D-Tetris-Spiel namens DTAUS.

Aber die Umlaute vermisse ich da ziemlich. Hmmmm. Ich hoffe, dass die SEPA-Schöpfer sich gesagt haben "wir versuchen erstmal den Krams europaweit *überhaupt* an's Laufen zu kriegen - die Sonderzeichen kommen in irgendeinem späteren Release". Ich hoffe.

Und auf die SEPA-Lastschrift bin ich auch sehr gespannt (das Feature interessiert uns als Verein am meisten, da wir ziemlich grenznah sind und uns schonmal Leute fragen, ob sie uns nicht eine Einzugsermächtigung für ihr niederländisches oder belgisches Konto geben können ... --> nein, im Moment noch nicht).



Mir fällt vor allem auf, dass bei Zahlungseingängen, die von Kunden bei der gleichen Bank kommen (Aachener Bank in meinem Fall), oft der Kundenname (ZP/ZE) in Groß-/Kleinschreibung und mit Umlauten im Kontoauszug steht. Oft (aber nicht immer) steht da "Gutschrift SB" im Verwendungszweck - sind das die Leute, die ihre Aufträge in die Automaten bei der Bank eintippen?

Viele Grüße,

Chris

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.