dateien mit über 1000 Lastschriften senden

Hallo,

stelle den Kunden von HBCI-PIN/TAN auf EBICS um. Das kann Sfirm, das kann auch die SI, und da gibts kein mir bekanntes Postenlimit.

Otto

Hally cyberjack,

das Limit von 999 Zahlungen (oder 1.000) ist RZ-seitig. Es gibt sogar RZs, die erlauben nur 300 Zahlungen "pro Durchgang".
Die Software kann nur eines machen: Bei mehr Zahlungen als die RZ-seitige Grenze, die Zahlungen in entsprechende "Pakete" aufsplitten.

Stefan Balk

PS: Macht windata übrigens genauso

Im Anforderungsmanagement gab es die Forderung vor Jahren schon
10.000 per Internet-Banking waren gewünscht.... Jeglicher Kommentar zwecklos imho.

Es gibt einen Parameter im Institutssatz für den Upload im Internet-Banking, Maximalwert ist aber auch 1000. Du könntest also nur für Internet-Banking die Anzahl Posten reduzieren, mehr ist nicht drin.

Hallo zusammen,

wir haben den Max-Wert bei der SI auf 3.000 setzen lassen (geht wirklich). Es kann auch klappen, wenn ein Kunde 3000 Posten per DTA-Upload überträgt, ist dann aber von einigen Faktoren wie Anzahl VWZ, derzeitige Verarbeitunngsgeschwindigkeit der SI, der eingen Uploadgeschwindigkeit ... abhänig, und klappt nicht zuverlässig.
Zuverlässig klappen 1.000 Posten.

@ cyberjack:Deshalb, wie die Kollegen schon sagen: Dein Kunde würde sich über Ebics freuen. Dort sind bankrechnerseitig auch 250.000 Posten mit 14 VWZ kein Problem. Einziges Problem könnte hier die Kundensoftware (z.B. SFIRM) und die Leistung des Kundenrechners sein.

Gruß bt

250.000 Zahlungen sind für SFirm32 definitiv ein Problem, losgelöst vom Rechner. Vermutlich dauert selbst auf nem MacPro (8Kerne mit 8 GB RAM) die Nachverarbeitung alleine mehrere Stunden.
Dafür ist die Datenbank auf MS-Jet Basis alles andere als optimal.

Fremddatei versende könnte sauber laufen.

Leute, lasst die Kirche doch mal im Dorf.
Ich komme vom Land. Die größten Dateien kommen von unserem Kreis und von unseren Kommunen. Das sind maximal 20.000 Posten und die sind kein Problem für SFirm und EBICS auf einem "normalen" Windowsrechner. Ein Unternehmen, dass 250.000 Zahlungen auf einen Rutsch rausschickt wird wohl etwas größer sein und eine entsprechende Austattung (sprich Großrechner und z.B. Travic-Link) verfügen. Schließlich wollen die Verträge, die hinter den Zahlungen liegen, auch noch verwaltet werden. Oder kennt hier jemand eine Versicherung o.ä., die ihren ZV mit SFIRM, PC, MC oder WinData verwaltet?

CU
Frank

Nachtrag @bt:
Was passiert bei SFIRM in der Nachbearbeitung einer Fremddatei? Das Ausgabeprotokoll wird erstellt. Das erstellen einer Druckdatei von mehr als 10.000 Seiten kann auch unter Word schonmal einen Rechner in die Knie zwingen. Vom Druckertreiber gar nicht zu reden. Aber gedruckt habt ihr das Protokoll doch hoffentlich nicht, oder ?

@Fellini:
wir haben hohe 6-stellige Postenanzahlen in Dateien, die wir gerne per SFirm versenden würden, wenn es denn ginge (per EBICS soll das ja gehen!), denn auch Unternehmen mit vielen Kunden sehen ZV eher als Kostentreiber und sparen dort wo's geht - und Großrechnerlösungen sind teuer!!!
Deshalb ist ja die Lösung 'Fremddateien via Internet' (EBICS) so angesagt und wird euch wohl auch ganz neue Kundenschichten erschließen können.

Gruß
HaJo

Hallo zusammen,

wie gesagt wir habe nur getestet. Derzeit bekommen wir die Datei mit ca. 250.000 Posten noch per Datenträger. Doch auch das soll irgendwann ein Ende haben. Travic-Link ist da so eine Alternative. Der Kunde hat auch einen Multicom-Server von CocoNet im Einsatz. Der kann in der installierten Version derzeit nur FTAM und da würde die Übertragung auch bei FLAM-Komprimierung rund 7 Stunden dauern. Eigentlich hab ich die Hoffnung, dass der Kunde seinen Multicom-Server updatet und der dann EBICS kann. Dort sollte das Mengenproblem nicht bestehen. Zumindest behauptet CocoNet, dass Dateien jeder größe verarbeitet werden könnten.

Schaun wir mal.

Gruß bt

Hallo Sven,

hier solltest du direkt mit deiner Sparkasse (KölnBonn?) reden. Der prosystems-Bankrechner ist eine Individuallösung, die nicht über die SI läuft. Die Kollegen können hoffentlich mehr in ihren internen Logs erkennen.

CU
Frank