Hallo zusammen,

einen habe ich noch und ich hoffe, ich bin hier im richtigen Forum. Es geht um AZV-Dateien bzw. um die ZKA-Spezifikationen für eine DTAZV-Datei. Im Gegensatz zum IZV gibt es im AZV ja keine "Unterteilung" in logische Dateien. In den DTAZV-Spezifikationen ist weder explizit geregelt, dass eine DTAZV-Datei nur genau eine Auftraggeberkontonummer enhalten darf, noch dass mehrere Auftraggeberkontonummern verwendet werden können.

Wir haben nun das Problem, dass unser Rechenzentrum die DTAZV-Dateien, die mit mehreren Auftraggeberkontonummern über FTAM reinkommen, weder sauber auf die EU zu jedem einzelnen Konto prüfen kann, noch sauber in der nachfolgenden Sammler-DB anzeigen und verarbeiten kann. Eine aufwändige manuelle Nachbearbeitung ist erforderlich.

Kennt jemand dieses Problem? Wie habt ihr es gelöst? Ich persönlich halte nichts von der im Moment praktizierten Lösung, dass eine Datei mit mehreren A-Konten gelöscht wird und der Kunde die DTAZV-Datei quasi sortenrein erneut einreichen muss...

Gruß, Thorsten

Warum ?? Der Kunde reicht uns doch Sachen ein, die so nciht verarbeitet werden können, weil sie nicht den Regeln entsprechen. Wenn es ein DTAUS geht muss es ja noch lange nicht bei DTAZV gehen.
Mit welcher SW werden die nicht spezifikationskonformen Dateien erstellt? Ich würde die Dateien allein schon aus Erziehungsgründen zurückgeben. Man kann eine solche Rückgabe ja auch positiv (und das SFirm direkt mit *gg*) verkaufen .

CU
Frank

Mit dem "nicht regelkonform" bin ich mir nicht sicher, da ich halt keinen Punkt finde, wo steht, dass der Kunde darf oder halt nicht! Hast du da eine Quelle?

Die Dateien können mit allen Programmen erzeugt werden, (leider) auch mit sFirm32...

Gruß, Thorsten

Hmmm,
lesen bildet doch ...
Das Feld Q4 enthält nicht, wie ich bisher immer geglaubt habe, die AG-Kontonummer sondern "Ordnungsnummer gemäß Vereinbarung mit dem dateiempfangenden Kreditinstitut
(ggf. Kontonummer)". In Q3 steht die BLZ des "Dateieimpfangendes Kreditinstitut"
Die Daten in T3 (BLZ Belastungskonto) und T4b (Belastungskonto) haben damit fomell nichts zu tun. Richtig spaßig wirds, wenn man die Felder T6 (BLZ Gebührenbelastungskonto) und T7b (Gebührenbelasungskonto) dazunimmt.

Gemäß Spezi könnte uns ein Kunde eine DTAZV mit drei unterschiedlichen Belastungskonten bei Voba, Poba, und Deba schicken. Gebühren bitte z.L. Spardose ....
Imho gilt für eine solche Spezifikation immer: Was nicht ausdrücklich verboten ist, ist erlaubt. Nur glaube ich, daß die SI das gaaanz anders sieht.
Ich werd mich am Montag mal beim Zahlungsverkehrspapst schlau machen.

CU

Frank

ps: Nachzulesen ist das übrigens in der Anlage 3 zum DFÜ-Abkommen.

Ich geh anhand deines Wohnortes einfach mal von der SI aus. Da wir dieses Problem nicht kennen hab ich jemand gefragt, der sich damit auskennt *g*. Überprüfe einfach mal, ob in der Institutsadministration für die Sammler-DB der Parameter " DTAZV splitten" auf ja steht. Ein nein an dieser Stelle verursacht nämlich das von dir geschilderte Problem. Nebenbei überlebt bei einem DTAZV-"Sammler" ein fehlerfreier Auftrag, wenn ein weiterer nach den neuen K.O-Kriterien (fehlender IAN/BIC bei EU-Zahlungen) systemseitig abgeschossen wird.
Ach ja: Datensätze mit fremden (Belastungs-) BLZ im T-Satz werden auch abgewiesen. So genau setzt die SI die Spezifikation dann doch nicht um.

CU

Frank

Jau, SI passt. Von dort habe ich auch gerade die Bestätigung bekommen, dass - entgegen der ersten Aussage - sehr wohl alle im T-Satz Konten EU-mässig geprüft werden und nicht nur die "Nummer" in Q4.

Und den I-Satz schaue ich mir gerade an, danke für den Tipp. Mist, steht auf "ja". Any other idea?

Gruß, Thorsten

Hallo Thorsten,

imho wird die EU einzig und allein vom ELKO-Host geprüft. Wenn der nickt kommt die DTAZV in die SammlerDB und wird hier zerpflückt. Natürlich kannst du die Prüfgrenze für ELKO/EU in der SammlerDB auf 0,01 setzen(sprich die Zahlungen anhlaten), aber das macht imho genausowenig Sinn wie Disketten oder ELKOoEU immer durchzulassen. Technisch wäre beides aber möglich.

CU
Frank