Fremddatei senden: Verändert windata 8 den Namen des Zahlungsempfängers in der pain.008-Datei?

Hallo,

für einem Test von SEPA-Lastschriften habe ich eine Erst- und eine Folgelastschrift als je eine SEPA-XML-Datei im Format pain.008.002.02 an die Postbank geschickt. Die Bank des Lastschriftzahlers war die Sparkasse KölnBonn.

Die Erstlastschrift habe ich mit "VR-NetWorld Software 5" an die Postbank gesendet (Funktion "Datei zur Übertragung einlesen").

Die Folgelastschrift habe ich mit "GLS eBank Basis" (das im Großen und Ganzen "windata professional 8" zu entsprechen scheint - zumindest sieht es genauso aus) an die Postbank geschickt (Funktion "Fremddatei senden").

Diese Funktionen sollten ja den Inhalt der verwendeten XML-Datei eigentlich unangetastet lassen.

Frage: Ist das bei windata definitiv so, oder werden die Dateien doch in irgend einer Form verändert?

Ich habe nämlch festgestellt, daß auf dem Konto des Lastschriftzahlers bei der mit "VR-NetWorld Software 5" versendeten Erstlastschrift der vollständige Name des Zahlungsempfängers als "Begünstigter/Zahlungspflichtiger" erscheint, während bei der mit "GLS eBank Basis" versendeten Folgelastschrift dagegen nur eine abgekürzte Bezeichnung zu sehen ist, so wie sie in den Bankparametern stehen.

Meine Frage wäre jetzt, an welcher Stelle in der Kette jetzt der Name des Zahlungsempfängers verändert wurde - bei einer der beteiligten Banken oder in der Software?

Gruß,
Stefan

Bei VRNWS konnte ich den gesendeten XML-String im HBCI-Protokoll sehen - da wurde nichts verändert, und hier erschien ja auch der Name des Zahlungsempfängers korrekt im VWZ des Kontos des Lastschriftzahlers.

Bei windata habe ich leider kein so ausführliches Sendeprotokoll finden können, aus dem die tatsächlich gesendeten XML-Daten ersichtlich sind.

Bevor ich mich an die Bank wende, würde ich gerne erst einmal sicherstellen, daß die Software nichts verändert.

Nachtrag:
Bei der Funktion "Fremddatei senden" gibt es eine Option "Übertragene Zahlungen in die Statistik eintragen", die ich aktiviert hatte (Häkchen).
Nach der Übertragung der Datei wurden dann auch die Daten der Lastschrift im Bereich "Statistik" / "Übertragene Zahlungen" angezeigt. Schon hier wird unter "Auftraggeber" bzw. "Zahlungsempfänger (Kontoinhaber)" nicht der lange Name aus der XML-Datei angezeigt, sondern eine abgekürzte Schreibweise aus den Bankparametern. Ich habe daher schon die Vermutung, daß das nicht an der Bank liegt, sondern am Programm.

Eigentlich ist mir das ja egal; ich habe nur Sorge, daß das bei irgend einer Empfänger-Bank einmal zu Problemen/Rücklastschriften führen könnte, wenn der Zahlungsempfänger - abhängig vom verwendeten Sende-Programm - mal so und mal so lautet, ohne daß das in der XML-Datei unter <AmdmntInfDtls><OrgnlCdtrSchmeId><Nm> entsprechend ausgewiesen wird...

Oder wird der Zahlungsempfänger-Name vielleicht zusätzlich zur pain.008-Datei auch nochmal im HBCI-Protokoll übertragen? Wenn er in der XML-Datei unverändert bliebe, dann wäre das ja hinsichtlich des <AmdmntInd>-Elements in Ordnung.

Vielleicht kann ja mal der Entwickler von windata etwas dazu sagen...

Hi Raimund,

ja, das kannte ich, hatte das aber so interpretiert, daß die Zahlungen dann zwar in die Statistik eingetragen werden, die Datei an sich aber unverändert übertragen wird. Andernfalls würde eine spezielle Funktion "Fremddatei übertragen" neben der normalen Import-Funktion eigentlich keinen Sinn haben.

Aber ich habe inzwischen gesehen, daß in der HBCILOG.TXT die übertragenen pain.008-Daten alle protokolliert sind - allerdings nicht im Klartext, sondern als Hex-Code (3C3F786D6C2076657......). An den ersten 6 Zeichen sehe ich aber schon, daß das die Zeichen "<?xml" sind. Ich werde also mal versuchen, ob ich das mit Hilfe von Perl wieder in Klartext zurückverwandeln kann; dann sehe ich ja, ob die übertragenen Daten tatsächlich der Originaldatei entsprechen oder nicht.

Gruß,
Stefan

Eine weitere Test-Lastschrift hat ergeben, daß das Deaktivieren der Option "Übertragene Zahlungen in die Statistik eintragen" rein gar nichts ändert - die beiden Elemente werden weiterhin manipuliert.