Import-Beschränkungen bei VR-NetWorld Software

Wertes Forum,

ich habe da mit einem Bank-Mitarbeiter einen kleinen Disput, und bitte um fachkundige Meinung.

Ursache sind Probleme beim Import von SEPA.XML-Datei in VR-Networld Software.
Nachdem der Vorgang dann auch seitens des FIDUCIA-RZ geprüft wurde, steht die Aussage im Raum "Geht nicht, in der SEPA.XML sind ja mehrere Sammler drin".

Hier mal die Antwort des FIDUCIA-RZ

<Zitat>
Soll eine XML-Datei per HBCI/FinTS übertragen werden, sind folgende Punkte zu beachten:

- Eine HBCI-Nachricht darf nur einen einzigen Einzel- bzw. Sammelauftrag enthalten
- Ein Sammelauftrag darf maximal 500 Sätze enthalten
- Eine SEPA-Sammellastschrift darf nur eine Ausführungssequenz enthalten. Erstmalige, wiederkehrende oder letzmalige Lastschriften müssen jeweils in einem separatem Auftrag eingereicht werden

Bei einer Einreichung über die Datenverarbeitung in der eBanking Business Edition oder EBICA sind die ersten beiden Punkte nicht relevant.
</Zitat>

Und nun die Gretchen-Frage:

A )
Die genannten Einschränkungen gelten nur für den Import in die VR-Networld-Software.
Für den Upload via Webseite gibt es keine Einschränkungen

B )
Die genannten Einschränkungen gelten nur für den Upload via Webseite.
Für den Import in die VR-Networld-Software gibt es keine Einschränkungen

Welche der beiden Varianten A oder B ist zutreffend ?

Ich bedanke mich für sachdienliche Antworten.

mfg
Wolfgang Schwarz

Vielen Dank für die Antwort, aber diese ist mir nicht ganz verständlich

Die Thematik mit den "sortenreinen" Sammlern ist mir bestens bekannt, in unserer SEPA-Anfangsphase vor 1 1/2 Jahren habe ich diese mehrfach überarbeitet.
Unsere Sammeler sind absolut "sortenrein" getrennt nach Typen (CORE,COR1,B2B), Erst/Folge-Lastschrift, Fälligkeiten.
Also kein "Misch-Masch" !

Und per Webseite kann ich nur eine Datei mit *einem* Sammler hochladen.
Vielleicht habe ich ungeschickt gefragt, aber wieso die Variante B ganz falsch sein soll verstehe ich nicht:

Mein Verständnis:
1.) Bei Upload via Webseite ist jeweils nur *eine* Datei mit *einem* Sammler möglich.
2.) Bei Import in VR-Networld kann *eine* Datei *beliebig viele* Sammler haben.

Im Disput mit dem Bank-Mitarbeiter stellt dieser den Sachverhalt 1.) und 2.) genau umgekehrt da, und begründet dies auch mit der Fiducia-Antwort.
Diese interpretiere ich aber genau wie vorstehend beschrieben.

Auf mein Gegenargument "Dann können wir ja alles per Webseite einreichen da gibt es keine Einschränkungen" habe ich bisher keine Antwort erhalten.

Das Volumen liegt übrigens bei 200-300 Lastschriften, da können wir uns auf das Thema "sortenrein" beschränken.
Nach meinem Verständnis der Weg "SEPA.XML" als Import in Banking-Software deshalb gewählt, um der Problematik "nur ein Sammler/Datei" aus dem Weg zu gehen.

Was heißt bitte "offensichtlich" ?
Gibt es die Möglichkeit oder nicht ?

Ich wurde seinerzeit (ca. 02/2014) von Bankern und Anwendern förmlich genötigt, SEPA.XML so zu gestalten das jeweils nur ein Sammler enthalten ist.
(was in einem konkreten Fall dazu geführt das bei einer Tankstellen-Abrechnung 16(!) SEPA-Dateien erzeugt wurden).
Infolge dessen sind alle unsere Anwender welche bisher Ihrer alten DTAUS-Dateien über ein Webportal importiert haben, in Anschluß auf eine Banking-Software umgestiegen sind um nur *eine* Datei importieren zu müssen.
Echter Import, nicht Datenschleuder !

Gibt es da also eine Änderung, das inzwischen SEPA.XML mit mehreren Sammlern via Web-Portal importiert werden können ?
Das wäre mir neu !

So um das Ganze zu versachlichen, einfach mal die Fakten:

Die Spezifikation für SEPA Dateien steht in der jeweils aktuellen Anlage 3 des DFÜ Abkommens (EBICS), ist für Deutschland also quasi die Mutter der Spezifikation.
EBICS nutzt genau diese Vorgaben

Für andere Wege kann es verfahrensabhängige Einschränkungen geben.
Für FinTS sind diese Einschränkungen in der FinTS Spezifikation definiert:
- Nur ein logischer Sammler in einer Datei
- Ausführungsdatum 01.01.1999 bei nicht terminierten Überweisungen
- ....

Für andere Verfahren insbesondere Webportale kann es ebenfalls Einschränkungen geben. Da die meisten Webportale keine standardisierte Verfahren nutzen (ausser wenn Sie Multibankenfähig sind), kann es auch keine pauschale Aussage dazu geben , was bei Portalen möglich ist.
Zu den Verfahrensspezifischen Einschränkungen kommen noch die Bank/Rechenzentrumsabhängigen Einschränkungen je Verfahrensweg, wie z.B. die Anzahl der Transaktionen pro Datei/Sammler.

Odin hat -wenn ich das richtig gesehen habe- eine Aussage für die eBusiness Lösung der Volksbanken / Raiffeisenbanken am Rechenzentrum FIDUCIA getroffen. Da scheinen Dateien mit mehr als einem Sammler möglich zu sein. Ich selber weiß vom Internetbanking der Volksbanken und Raiffeisenbanken am Rechenzentrum der GAD, das dort die gleiche Beschränkung wie bei FinTS gilt. Wie das bei den Sparkassen, der DeuBa, CoBa usw. aussieht? Keine Ahnung.

Wenn Du sicher sein möchtest, dass Dateien, die sich nach der Mutter der Spezifikation richten auch ausserhalb von EBICS übertragen werden können, bleiben nur Kundenprodukte, die die Aufträge für FinTS neu zusammenstellen, sofern das notwendig ist. Die Programme leben seit Jahren mit der Krux, dass sie alle Besonderheiten irgendwie berücksichtigen müssen.

Viele Grüße

Holger

Das ist leider das Schicksal der Softwarehersteller. Auch bei den Bankingprogrammen. Wenn etwas nicht funktioniert, ist es immer die blöde Software, nie die Bank......
In der VR-NetWorld Software gibt es in den Einstellungen für den Export von Umsätzen im MT940 Format einen Schalter, der eigentlich heißen müßte: Exportiere den Datenschrott, den mir die Bank als MT940 geliefert hat als MT940 und ignoriere alle fehlenden Pflichtfelder.......... (da das zu lang ist, heißt die Option nur "MT940 Export ohne Prüfung durchführen".........).

Ganz so rosig war es bei DTA übrigens keineswegs. Auch hier gab es Unterschiede und Unzulänglichkeiten nur waren die Möglichkeiten und damit die Ausreißer nicht so vielfältig und das Format gab es schon viel länger, womit sich einiges raus geschliffen hat. Daher für SEPA Formate: Die Hoffnung stirbt zuletzt.......

Viele Grüße

Holger

PS Der Titel des Threads ist eigentlich falsch. Die VR-NetWorld Software hat diese Beschränkungen beim Import nicht, sie behebt (besser umgeht...) vielmehr Probleme die durch die verfahrensspezifischen Beschränkungen existieren durch den Import der Zahlungen.

@Infoman,

nein nicht wirklich. Das Problem hier ist einfach Wissen. Sprich der der am wenigsten Ahnung hat, müßte genau wissen, was über welchen Weg möglich ist und dann seiner Software sagen, was er braucht.
Daher sind die Buchhaltungsprogramme, die zwar Zahlungsdateien erzeugen, aber keinen eigenen Versand implementiert haben, die mit der Ar....karte. Wenn man für alle Beteiligte das Wissen und den Aufwand minimieren möchte, bleibt eigentlich nur der Weg über ein Kundenprodukt, welches die für diesen Anwender, dem gewähltem Verfahren und der Bank notwendigen Anpassungen vornimmt.

Viele Grüße

Holger

Nachtrag:

Eben im Bett komme ich so ins grübeln

<Zitat aus der FIDUCIA-Antwort>
...
- Ein Sammelauftrag darf maximal 500 Sätze enthalten
...
</Zitat>

Also bei einer lokal installierten Anwendung welche lokale Daten importiert und dabei keinerlei Online-Aktivtäten benutzt, finde ich so eine Beschränkung sehr merkwürdig.
Und m.E. haben wir Anwender welche über lokale Banking-Software weit über 1000 Lastschriften aus einer Datei importieren. Bin ich mir sicher, müßte ich aber erst raussuchen.

Ich kanns einfach nicht glauben, das die Restriktionen für lokale Software gilt und für Webportale nicht.

Die pauschale Aussage "idealerweise an die BPD" (oder UPD), ist nicht immer zutreffend, denn einige Banken/Produkte werden zu stark beschnitten, obwohl die Technik mehr kann.
exemplarisch möchte ich hier auf den Kontoabruf (Umsätze) hinweise, der in der BPD oft mit 30-90 Tage beschränkt ist, obwohl evtl. (nicht immer) viel weiter in die Vergangenheit zurückgegriffen werden kann.

EBICS ist teilweise ein nicht unwesentlicher Kostenpunkt und daher je nach Unternehmen/-größe/Branche nicht unbedingt favorisiert.

Das generelle Problem ist ja, wie bereits von Holger Fischer auf den Punkt gebracht da es entweder das RZ nicht anders umsetzen kann oder die Banken individuelle Vorschriften machen.

@Holger Fischer
aus dem vorgenannten Zitat sowie

stellt sich aber die Frage, ob statt Export/Import nicht doch eine Alternativ möglich ist


daher hatte ich ja angedacht, ob nicht auf Code von Drittanbietern zurückgegriffen/implementiert werden kann, da diese ja das Fachwissen "einbringen".
(ein Autohersteller stellt doch auch keine eigene Autoreifen usw. her, sondern greift auf die Kompetenz des Zulieferers/Pneu-Herstellers zurück.)

es geht ja auch nur darum, Vergleichsmöglichkeiten zu schaffen.
Dem einen liegt der Import und die einhergehenden Kontrollmöglichkeiten mehr, andere wären schon aus Gründen Firmenstruktur mit EBICS besser beraten. Da spielen eine Menge Faktoren eine Rolle und selten ist eine Ideallösung möglich.