Hallo Sparkässler und liebe BIVG-Kollegen,

Grosskunde hat mehrmals im Monat Dateien von ca. 10.000 Lastschriften, die er per HBCI PIN/TAN rausschickt.

SFirm oder die SI stückelt die Zahlungen in 1.000er Pakete.

Der Kunde frägt an, ob man diese 1.000er Grenze nicht erhöhen kann.

1. Frage: Geht das? Wie?
2. Frage: Ist das SI oder BIVG Baustelle?

Gruß

cyberjack

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

Hallo Cyberjack,

das ist SI-Baustelle. Mehr als 1000 Posten werden als Sammler nicht akzeptiert. Ein Eintrag in der BPD sagt aus, das eine Software mehr senden soll und wird damit zum Stückeln aufgefordert. Würde ein Software grüßere Pakete senden, würden diese irgendwann abgelehnt.
Test sind mal auf ca. 1400 Datensätze gekommen, das ist aber abhängig vom Inhalt, z.B. Anzahl VWZ-Zeilen.

1000 Posten per FinTS ist recht viel, es gibt nur wenige Banken die mehr akzeptieren. Highlight ist IMHO die Coba mit 4000.

Für 1000 Posten oder mehr ist aber eh EBICS die bessere Wahl....
FinTS ist keine Massenzahlungsverkehrsschnittstelle, schon per Definition und technischer Auslegung nicht.

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

Hast du schon mal was von EBICS gehört??
Dateien mit 10.000 Posten passen eindeutig nicht zum Privatkundenprodukt Pin/Tan !!

Nur mal so zu deinen Fragen:
1. Ja, Bring einen Antrag in den APA der SI.
2. Siehe 1. SFirm ist die Dateigröße egal.

Aber nochmal mit Nachdruck: Tu dir und dem Kunden einen Gefallen und stell ihn auf EBICS um!!

CU

Frank

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

Ich glaube, ich hätte mal gehört, dass dieser Parameter im Institutssatz eingestellt wird. Dann hätte das nichts mit SI, sondern eher mit der eigenen Administration zu tun.

Nichtsdestotrotz wäre hier EBICS wirklich angebracht.

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.

Ah, ok, dann war der Wunsch Vater des Gedanken. :?

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

Wo soll hier ein Problem sein, dass bei P/T nicht besteht? Der PII 500 mit 64 MB und Vista wird bei jeder Software in die Knie gehen. Will sagen, man kann in einem gewerblichen Umfeld eigentlich von einer ordentlichen Rechnerausstattung ausgehen. Wenn die nicht da ist, ist es auch nicht verwerflich, den Kunden darauf hinzuweisen. Da ist dann imho nicht die Software schuld. Weder SFirm noch PC Einzige Ausnahme: Norton!! Die ist immer schuld !!! :twisted:

CU
Frank

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.

Hallo Captain,
danke für Deine Antwort !

Hallo Frank,
das Problem mit der Menge würde bei HBCI (wenns der Bankrechner könnte) genau so bestehen. Es hängt einfach an der Struktur von SFIRM und den anderen EB-Programmen. Viele Programme (ohne Namen) fangen nicht mal an solche Datenmengen zu verarbeiten oder hängen sich schon beim Erstellen des DFÜ-Auftrages auf.

Kurz zu unserer Testumgebung: P4-3GHz, 2 GB RAM WinXP. Alles was Ressourcen kostet ausgeschalten (außer Antivir und Firewall - und es war nicht der Norton).
Unterschreiben und übertragen einer Fremddatei mit 250000 Zahlungen und je 14 VWZ via EBICS (AA IZV) hat funktioniert. EU-Prüfung am Bankrechner hat auch funktioniert und die Datei hätte gebucht werden können. In der Nachverarbeitung hat sich SFIRM dann erhängt bzw. wir haben die Nachverarbeitung nach einigen Stunden abgebrochen.

Gruß bt

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 ?

Nicht nur...ist nen bisschen Modulabhängig.
Die Nachverarbeitung setzt jede Einzelzahlung auf erledigt und z.B. bei aktiviertem Dispomodul und eingeschalteter Splittung werden kistenweise Plandaten erzeugt.

@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 lalala,

EBICS ist hier nicht der begrenzende Faktor, da teilweise schon heute Versicherungsunternehmen via EBICS bei Bankrechenzentren aufliefern.
Man muss heute auch bei hohen Postenzahlen nicht mehr umbedingt Sonderlösungen oder Großrechnerverfahren einsetzen.

Ob SFirm32 für derartige Übertragungen geeignet ist, müsste getestet werden. Beim reinen Versenden von Fremddateien glaube ich das es funktioniert. Als Import denke ich wird es sehr schwierig, da die von SFirm32 verwendete Datenbank hier nicht mehr optimal ist.

Es gibt auch spezielle Transfertools z.B. auf Win-Basis, die nichts anderes machen (können) als große Zahlungen (Fremddateien) oder EBICS (oder auf anderen Wege) zu versenden.

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 @all,

passend zu dem Thema >1000 Lastschriften habe ich folgendes Problem:

Bei Verwendung von EBICS(!) und Transfer via Internet (also KEIN ISDN) kommt es zum Verbindungsabbruch. Bei kleinerer Anzahl klappts.

Hier: ca. 6000 Lastschriften
Fehler: EBICS: Fehler : 0 Code : 8, de.ppi.fis.travic.ebics.kernel.transport.CommunicationException: Bei der Kommunikation mit https://sparkasse.prosystemsit.de/ebicsweb/ebicsweb: Software caused connection abort: socket write error

Version: Sfirm32 2.2.1 neuster Patchlevel

Hat jemand eine Idee?

Schöne Grüße
Sven

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