Guten Tag,

ich grübele gerade über die im Titel gestellte Frage nach. Nach der Spezifikation 2.7 darf man technisch gesehen unendlich viele "PmtInf" Blöcke pro Datei verwenden, gleichzeitig schränkt aber z.B. die Bundesbank die Anzahl auf maximal 999 "PmtInf" Blöcke ein, und z.B. die UniCredit Bank empfiehlt maximal 100 "PmtInf" Blöcke in eine Datei zu schreiben.

Was sind die Hintergründe für diese Einschränkung?
Und wie wird diese Grenze so generell bei deutschen Banken gehandhabt?
Haben alle Kreditinstitute diese Einschränkung?

Anlagen:
SEPA LS Version 2.6 - Technische Spezifikation BBK - Abschnitt 2.2.2
UniCredit - max 100xPmtInf - Seite 14

Das entscheiden die Banken und steht in der BPD im HICCMS im vorletzten Feld.

Das wäre dann ja bankspezifisch, wenn ich das richtig verstehe.
Gibt das eine bankübergreifende Auflistung, damit man mal einen Eindruck bekommt, was so übliche Werte sind? I
ch konnte per Google auf die schnelle nichts finden.

Hallo Jens,
In HBCI FinTS darf immer nur eine PmtInf vorkommen

Seitens der Spezifikation sind 9.999.999 PmtInf mit jeweils 9.999.9999 Einzeltransaktionen möglich. Das ist aber nur die technische Spezifikation dessen was theoretisch machbar ist.
Was in der Praxis geht hängt vom Übertragungsverfahren und den technischen Restriktionen der jeweiligen Systeme ab.
Bei EBICS ist die Grenze der möglichen Wiederholungen auch bei den Einzeltransaktionen deutlich höher als bei HBCI/ FinTS
Bei HBCI/FinTS immer nur eine PmtInf gesendet werden mit einer begrenzten Anzahl der Einzeltransaktionen. Wie viele das sind hängt oft davon ab, ob das System noch während des Dialoges alles bucht und verarbeitet. So gibt es hier z.B. Unterschiede, ob man eine bankverwaltete terminierte Überweisung oder eine Überweisung zur sofortigen Ausführung oder eine Lastschrift einreicht. Wie viele Transaktionen möglich sind, erfährst Du technisch aus den BPDs. Aber alles was da kommt ist eine Momentaufnahme, die sich durchaus ändert.

Viele Grüße

Holger

Vielleicht OT aber:
Sobald der Übertragungsweg HBCI im Spiel ist, dann ist sowieso nur *ein* PmtInf-Abschnitt pro Datei möglich. Und HBCI ist dann im Spiel wenn:
- eine SEPA.XML per Webseite hochgeladen wird.
- eine veraltete Banking-Software benutzt welche noch nicht mit EBICS arbeitet.

Dieser Logik folgend haben kenne ich einen Anwender für den wir plötzlich statt *einer* DTAUS insgesamt *14*-SEPA.XML-Dateien erzeugt haben. Es gibt nämlich in unserer Warenwirtschaft einen Schalter "mehrere Payment-Abschnitte erlaubt J/N".

Über die Freude das nun 14 Einzel-Dateien hochgeladen werden müssen, und 14 mal mit TAN bestätigt werden müssen kann ich nichts berichten.

Mit entsprechender Übung geht das dann ja auch zunehmend schneller

@all: Vielen Dank für die Infos.

Das ist eigentlich genau der Hintergrund meiner Frage. Im Endeffekt müssen wir vielleicht unser Datei-Erzeugungs-Modul umschreiben, damit es mit diesen Restriktionen umgehen kann. Aber einzelne Dateien hochladen will ja nun auch keiner.

Hallo Jens,

Wen ihr Dateien per HBCI/FinTS versenden wollt, habt ihr zwei Möglichkeiten:
Ihr verlasst euch darauf, dass die vom Kunden verwendete Software die Datei im Zweifel importieren kann und gemäß dem Wunsch der Bank neu aufbaut oder
Ihr habt ein paar Schalter mehr zu berücksichtigen als nur die Anzahl der Dateien hochschrauben. Bei Überweisungen muss z.B. derzeit der Ausführungstermin mit dem Eintrag 01.01.1999 entwertet werden.

Viele Grüße

Holger

Ja, wobei ich jetzt die Einzelposten eines Sammlers meinte, also die <CdtTrfTxInf>'s. In FinTS natürlich nur ein <PmtInf>. Und das ist noch die alte Angabe für das DTAUS Format. Inwieweit diese Daten auch für SEPA übernommen werden wird sich glaube ich noch raussstellen.


Nicht das ich wüßte. Habe in dem Feld auch schon eine 200 stehen sehen.

Das mit den 14 hochzuladenden Dateien ist aber grundsätlich ein anderes Problem! Und zwar die Sortenreinheit.

Bisher bei DTAUS-Lastschriften wurden keine Belastungstermine mitgegeben und es gab keine Erst-/Folgelastschriften.

Bei SEPA-Lastschriften muß für jede Sorte (Belastungstermin- und Erst/Folge) eine neue Datei angefangen werden. Wir hatten das dieser Tage schon mal: Wenn man sich auf "Zahlungstermine" beschränkt und diese für alle Lastschriften setzt, dann braucht man sehr viel weniger Dateien, als wenn es jeden Tag Belastungstermine gibt.... So kann man dann ggf. auch mit Übertragung per HBCI und TAN-Eingabe leben.

Kann es nicht auch sein, dass jede einzelne Zahlung als Sammler deklariert ist? Das würde bei 14 Zahlungen die 14 Übertragungen erklären. Unter Ebics können mehrere logische Sammler übertragen werden, unter HBCI (wie schon geschrieben) nur einer. Aber warum wird dann jede einzelen Zahlung als einzelner Sammler deklariert? Ich denke, das hier der Hase eher im Pfeffer liegt und ihr einmal in dieser Richtung forschen solltet.

@Holger Fischer: Du hast das auf dem Workshop so gut erklärt, vielleicht machst du das hier auch noch einmal.... Stichwort: Bauklötze ....

So nicht richtig.
Unter Sortenreinheit versteht man in der Regel dass nur eine Art von Lastschrift in einer Datei erlaubt sind. Sprich nur Basis, nur Firmen oder nur Eil Lastschriften.

Das ist die einzige Restriktion in der SEPA Spezifikation die zwingend eine neue Datei erfordert.
Alles andere kann von der Spezifikation her in eine Datei gepackt werden.

Innerhalb der SEPA Datei gibt es die Möglichkeit mehrere logische Sammler einzustellen. (Ähnlich einer Multi DTA Datei)
Auf der Sammlerebene sind u.a. die folgenden Eigenschaften für alle Aufträge innerhalb eines Sammlers definiert:
- Tag der Belastung
- Lastschriftsequenz
- Gläubiger ID

D.h. immer dann, wenn sich einer dieser Eigenschaften für mindestens einen Auftrag ändert muss ein neuer Sammler innerhalb der Datei erzeugt werden. Sinnvoller Weise werden alle Transaktionen mit den gleichen Eigenschaften in einem Sammler zusammengefasst.

Das gilt erst mal grundsätzlich für eine SEPA Datei, die der Spezifikation entspricht.

Unter EBICS kann so eine Datei mit einer beliebigen Anzahl von Sammlern auch eingereicht werden.

Unter HBCI/FinTS gibt es für die Einreichung von SEPA Dateien verfahrensspezifische Restriktionen. Die Wichtigste ist, dass nur ein Sammler pro Datei erlaubt ist.
Das heißt, immer dann, wenn sich die oben genannten Eigenschaften ändern, muss für eine Übertragung per HBCI eine neue Datei angefangen werden.

Diese Restriktion gilt für HBCI/FinTS. Sie gilt nicht zwingend für den Dateiversand über andere Verfahren wie z.B. dem Datei Upload im Internetbanking. Hier bestimmt ausschließlich die Umsetzung der Bank (bzw. dessen Rechenzentrums), ob ein oder mehrere Sammler innerhalb der Datei erlaubt sind.


Danke! Am Anfang zieren sich alle mit den Bauklötzen und dann sind sie froh, wenn es Klick macht. Das mit den Bauklötzen ist einfach, wenn man die vor sich hat. Sie nur schriftlich zu erklären ist gar nicht so einfach. Ich mach mir mal ein paar Gedanken dazu (ich meine die Idee mit den Bauklötzen ist aus einem Beitrag von mir hier im Forum sogar entstanden)

Viele Grüße

Holger

Anmerkung dazu:
In den 14 Übertragungen waren insgesamt ca. 120 Lastschrift-Aufträge enthalten.
Die Lastschriften waren "sortenrein" nach CORE/B2B/FRST/RCUR/Termin vorsortiert.
Jede Kombination von "Sorte" kam nur einmal vor.
Weniger Dateien waren nicht möglich.
Eine Beschränkung auf "Zahlungstermine" ist in der Mineralöl-Branche nicht möglich.
Da geht es "33.000l-Tankzugweise", und die Belastung muss exakt am vereinbarten Termin erfolgen. Da achten sowohl Zahlungspflichtiger sowie Zahlungsemfänger pingelig genau drauf.

Ich denke mal da ist kein Hase im Pfeffer.

Diese Informationen, vor allen mit der Gesamtanzahl der Lastschriften und Aufteilung, hatte ich nicht. Insofern hast Du recht mit dem Hasen und dem Pfeffer.

Bietet sich für den Kunden dann nicht EBICS als Übertragungsart an? Damit wären die geschilderten "Probleme" aus der Welt.