Fremddatei versenden... (Komma in DTA-Empfängernamen)

 
Heart
Benutzer
Avatar
Geschlecht:
Beiträge: 349
Dabei seit: 11 / 2003
Betreff:

Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 11.09.2009 - 12:27 Uhr  ·  #1
Hallo,

ich habe gerade eine DTA-Datei (Löhne und VWL) per "Fremddatei einlesen..." in sFIRM über HBCI mit Chipkarte (Fiducia) versendet. Gebucht wurden nur die "kleinen Beträge" (also die VWL), jedoch nicht die Löhne.

Im Protokoll sagt mir sFIRM

Code
*Sammler verarbeitet, 029 Sätze waren fehlerhaft. (S)
*Name des Empfängers fehlt (Code 3290)
1 (S)
*Name des Empfängers fehlt (Code 3290)
3 (S)
.....usw usw für die 29 Überweisungen

Ein Name ist im DTA-Satz definitiv überall drin.
DTA-Checkprogramm sagt auch, dass alles i.O. wäre mit dieser DTA-Datei. (VR-NetWorld Software zB kann sie zudem auch problemlos einlesen)

Das Format der Empfängernamen ist
"NACHNAME,VORNAME"

bei den (gebuchten) VWL war kein Komma im Namen (UNION INVESTMENT, LBS, ....).

Hat sFIRM hier Probleme mit Fremddateien einzulesen, die ein Komma im Empfängernamen beinhalten :roll: :?:
Michael Döring
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 1495
Dabei seit: 07 / 2008
Betreff:

Re: Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 11.09.2009 - 12:38 Uhr  ·  #2
Komisch. Komma ist im DTA zugelassen. Welches DTA-Checkprogramm wurde denn verwendet?
Heart
Benutzer
Avatar
Geschlecht:
Beiträge: 349
Dabei seit: 11 / 2003
Betreff:

Re: Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 11.09.2009 - 12:41 Uhr  ·  #3
Captain FRAG
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Westfalen
Beiträge: 5096
Dabei seit: 05 / 2003
Betreff:

Re: Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 11.09.2009 - 12:46 Uhr  ·  #4
Beim Eilesen wird doch eine Rückmeldung erzeugt, da müssten eigentlich Fehler aufgefallen sein.

DTA prüfen kann man auch mit SFirm. Da würde ich mal sowohl die Sicherungsdatei aus dem Archiv in Sfirm als auch das Original gegeneinander prüfen.

Abgesehen vom Problem: fertige DTAUS muss man nicht importieren, der reine Versand ist auch möglich.

Alles notwendige gibt es unter Datei->DTA Dateien->...

Interessant wäre auch die HBCI-Dialogdatei der Übertragung, da steht die effektiv versendete DTAUS drin.
Michael Döring
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 1495
Dabei seit: 07 / 2008
Betreff:

Re: Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 11.09.2009 - 12:56 Uhr  ·  #5
Diesem xpecto schenke ich nicht genug Vertrauen und bei VR Networld ist die Datei vielleicht einfach nur angenommen und inhaltlich nicht geprüft worden.
Wenn SFirm einen Fehler findet, gibt es auch einen Fehler nach meiner Erfahrung.
Falls das Programm "ZV-Tools" von Windata zur Verfügung steht, würde ich das immer bevorzugen für absolute Gewißheit.
Heart
Benutzer
Avatar
Geschlecht:
Beiträge: 349
Dabei seit: 11 / 2003
Betreff:

Re: Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 11.09.2009 - 13:21 Uhr  ·  #6
Habe die DTA-Datei gerade eben noch zusätzlich mit ZV-Tools geprüft.

Bis auf Kleinigkeiten wie "Kleinbuchstaben im Feld Überweisungsempfänger" war alles i.O. :?
Michael Döring
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 1495
Dabei seit: 07 / 2008
Betreff:

Re: Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 11.09.2009 - 13:45 Uhr  ·  #7
Das verwundert mich jetzt allerdings schon sehr.

Wäre die Datei sehr geheim oder würdest Du mir die als PN mal schicken wollen?
Heart
Benutzer
Avatar
Geschlecht:
Beiträge: 349
Dabei seit: 11 / 2003
Betreff:

Re: Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 11.09.2009 - 13:55 Uhr  ·  #8
Hmm, da sind Löhne/Gehälter einer größeren Firma drin.... also ja, die kann/darf ich nicht verschicken!
Michael Döring
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 1495
Dabei seit: 07 / 2008
Betreff:

Re: Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 11.09.2009 - 14:26 Uhr  ·  #9
Kann ich verstehen. Sehr schade. Ich programmiere auch Anwendungen für DTA und interessiere mich deshalb sehr dafür. Aber ohne Datei kann ich das Rätsel nicht lösen und nicht sagen, warum ZV-Tools und VR Networld die Fehler nicht anzeigen.

Kannste im Techtalk mal wenigstens einen der abgewiesenen Umsätze rein kopieren oder mir per PN schicken?
Michael Döring
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 1495
Dabei seit: 07 / 2008
Betreff:

Re: Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 16.09.2009 - 12:38 Uhr  ·  #10
Ist gelöst. Falls es nochmal jemand ereilt:
Es lag nicht am Komma sondern daran, dass das erste Verwendungszweckfeld leer war und erst im Erweiterungsteil begann.

Von FI weiß man ja, dass die keine leeren Erweiterungsteile akzeptieren. Bei Fiducia scheinen leere Hauptfelder ein Problem zu sein.

Grüße
Heart
Benutzer
Avatar
Geschlecht:
Beiträge: 349
Dabei seit: 11 / 2003
Betreff:

Re: Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 16.09.2009 - 12:53 Uhr  ·  #11
Hier die "offizielle" Antwort / Begründung, warum derartige Datensätze von der Fiducia (bewusst) abgelehnt werden:

Zitat
Wie schon in der Fehlermeldung/Rückmeldung des HBCI-Bankrechners beschrieben, fehlt der Empfängername.

Textfelder zu den Zahlungsbeteiligten sind Pflichtfelder. Wenn sie vorhanden sind, müssen sie gefüllt werden.

Aus dem Anhang (DTA-Satz.gif) geht hervor, dass der Kundenname im Erweiterungsteil fortgesetzt werden sollte (Anlieferung von 01 in Feld C19). Die Fortsetzung ist jedoch leer und damit fehlt der vollständige Empfängername.

Die Daten vom Kundenprodukt sind nicht korrekt angeliefert und werden daher zum Schutz vor Falschverarbeitung abgelehnt.
Der an diesem Beitrag angefügte Anhang ist entweder nur im eingeloggten Zustand sichtbar oder die Berechtigung Deiner Benutzergruppe ist nicht ausreichend.
Michael Döring
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 1495
Dabei seit: 07 / 2008
Betreff:

Re: Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 16.09.2009 - 18:04 Uhr  ·  #12
Och, jetzt verstehe ich das erst richtig. Fiducia begründet es also auch mit einem leeren Erweiterungsteil - hier der des Empfängers. Würde ja bedeutet, es wäre garnicht schlimm, wenn der Verwendungszweck erst im Erweiterungsteil beginnt.

Na ja, auch gut. Entpsricht dann 1:1 der Verarbeitung bei FI, die lehnen leere Erweiterungsteile - egal in welchem Feld - auch ab.

Was ich sogar verstehen kann, weil unnötig und eher ein Indiz für falschen Satzaufbau denn für gewollte Handhabung.
Heart
Benutzer
Avatar
Geschlecht:
Beiträge: 349
Dabei seit: 11 / 2003
Betreff:

Re: Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 17.09.2009 - 16:24 Uhr  ·  #13
Ja, nur die Sparkasse bucht derartige DTA-Dateien ohne Probleme durch.

Sparkasse in Bayern.... ist das nicht die FI!?
Michael Döring
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 1495
Dabei seit: 07 / 2008
Betreff:

Re: Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 18.09.2009 - 08:28 Uhr  ·  #14
Ob Bayern schon technisch im Backend fusioniert ist, weiß ich nicht. Formell ist es - soweit ich weiß - schon FI, ja.

Meine Info stammt aus Zeiten, als es noch SI hieß.
Captain FRAG
Benutzer
Avatar
Geschlecht: keine Angabe
Herkunft: Westfalen
Beiträge: 5096
Dabei seit: 05 / 2003
Betreff:

Re: Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 19.09.2009 - 10:16 Uhr  ·  #15
Die Migration der Bayerischen Sparkassen (ex IZB Soft) auf das FI Backend = OSPlus wurde in 10/2008 abgeschlossen.
Seit Mai gehts in Niedersachen und Thüringen (ex Finanz IT) weiter.
Heart
Benutzer
Avatar
Geschlecht:
Beiträge: 349
Dabei seit: 11 / 2003
Betreff:

Re: Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 21.09.2009 - 10:38 Uhr  ·  #16
...also heißt das ja im Umkehrschluss, dass die FI's derartig ("falsche") DTA-Dateien dennoch akzeptieren!
Michael Döring
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 1495
Dabei seit: 07 / 2008
Betreff:

Re: Fremddatei versenden... (Komma in DTA-Empfängernamen)

 ·  Gepostet: 21.09.2009 - 10:57 Uhr  ·  #17
Jau, scheint mittlerweile so zu sein.

Musste damals extra teuer unsere Konvertierung umschreiben lassen. Na ja.....

Und ob das nun "falsch" ist, darüber ist man sich ja nicht so ganz einig, wie man an den unterschiedlichen Verhalten der Programme erkennt :)
Wichtig ist ja nur, dass man es weiß und reagieren kann.
Gewählte Zitate für Mehrfachzitierung:   0