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

Moin moin,

kurz: B ist ganz falsch und A zum Teil.

Grundlegend:
HBCI / FinTS kann pro Nachricht/Auftrag nur einen "sortenreinen" Sammler verarbeiten - gilt für alle Banken; liegt am Standard...

Also nur eine Art von Zahlungen mit dem gleichen Ausführungstermin und bei LS auch mit der gleichen Sequenz.

Die genannte Postenbeschränkung ist RZ-individuell. In der freien Wildbahn geht es bei HBCi bis 1000 Posten hoch - mehr aber nicht.

Über das Web-Interface und auch über EBICS kannst du eine Datei hochladen, deren Inhalt dann aus mehreren Sammlers besteht.
Aber jeder Sammler muss in sich "sortenrein" sein. Also keine Mischung verschiedener Fälligkeiten oder Sequenzen.

Wenn eine ERP Software so ein "Misch-Masch" liefern sollte, heilen wir das in der Praxis meist mit einem Import der Zahlungen in die
Banking Software - welche auch immer - und versenden dann aus der Banking SW die Zahlungen. Die SW baut dann die Sammler
gemäß den Vorgaben richtig auf und gut ist. Oder die ERP-SW baut "richtig" eine Datei für den Upload im Internet-Portal oder für
EBICS oder verschiedene Dateien für HBCI.

Dh. der Datei Aufbau eurer Dateien aus eurer SW muss an den genutzen Übertragungsweg des Kunden angepasst werden können.
Es gibt keine Lösung für alles auf allen Wegen.

Od

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.

Ok,

dann muss ich dein Verständnis erweitern..

zu 1) abhängig vom Portal kann dein Verständnis richtig sein und das der Fiducia... es gibt bei den Fiducia Banken
ein "normales" Web-Banking und eines für "Profis"... die Funktion auch eine "Multi-Sammler-Datei" zu verarbeiten
ist in der Profi-Variante offensichtlich enthalten und smit geht der Weg.

zu 2) Meinst du wirklich Import oder "nur zum Versenden einlesen"... das sind 2 Paar Schuhe...
Bei der Variante nur Versenden, wird die Ursprungsdatei so genommen, wie sie ist und den
Bankrechner gegeben. Wenn die Datei mehrere Sammler enthält klappt das nicht.

Dann muss ein "echter Import" stattfinden... Und dann wird beim Versenden pro Übertragung auch nur
ein Sammler geschickt und nicht mehrere.

Ich vermute da liegt euer Missverständnis.

Und zu deiner Variante B: das Problme ist dann wohl die ungeschickte Wortwahl
in Zeile 1 .."nur"...
in Zeile 2 .."keine"..
Wenn komplexere Sachverhalte verkürzt dargestellt werden, wird die Darstellung oft - nicht immer - falsch.

Und, wenn die VR-NW nur als "Datenschleude"r zur Bank benötigt wird, ist die Alternative Bankig-Portal in der Tat
vllt die bessere Wahl.

Od

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 !

aua, "genötigt" hört sich aber schlimm an. Die Alternative wäre entweder EBICS gewesen oder keine direkte Verarbeitung mehr...

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

Hallo,

zunächst erstmal danke ich euch für die fachkundigen Antworten.

Als Software-Entwickler im Bereich der Warenwirtschaft bin ich doch verwundert das es in dieser Diskussion die Worte "kann","scheinen","offensichtlich" usw. gibt.
Warum gibt kein einheitliches "muss genau so und so sein" / keine pauschale Aussage ?

Dazu kommt das jeder Bankberater meint das seine Lösung / die Restriktionen seiner Bank die einzig richtigen sind.
(@Raimund: Und das so unserem gemeinsamen Kunde erzählt, der dann wiederum sagt "macht die Warenwirtschaft falsch", deshalb "genötigt" !)
Und anderswo in Deutschland ist es dann wieder andersrum.
Ich dachte mit SEPA wird alles besser/einheitlich, stattdessen ist das Chaos größer geworden.
Zu Zeiten von DTAUS gab es solche Diskussionen nicht.

Für mich ist im Kopf eingebrannt:
- bei Webportalen nur 1 Sammler pro Datei.
- keine Einschränkungen bei Importen in Banking-Software

Nun höre ich das es bei FIDUCIA "andersrum sein kann".
Was ist das für eine Selbstherrlichkeit bei den Entscheidern.

Mit Grausen erinnere ich mich noch an "Keine Einzel-Lastschrift" bei GAD.
Problem ist, und das macht mich ärgerlich, das unsere Anwender die ganzen Probleme in der Warenwirtschaft vermuten und wir uns zeitaufwendig rechtfertigen müssen.

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.

@all
wäre die Problematik evtl. dadurch zu beheben, dass man auf einen Gateway/API zurück greift bspw. http://figo.io/ bzw. https://subsembly.com/de/tools.html ?

@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

Ich denke auch mal das es nur sehr wenige Buchhaltungsprogramme mit eigenem Zahlungsversand gibt.
Der Grund warum wir das scheuen ist der riesige Aufwand der für die Authorisierungsverfahren (PIN/TAN/Chip/Sicherheitsdateien usw.) erforderlich ist, die dann auch noch von Institut zu Instutit unterschiedlich sind und sich dauernd ändern. Das ist m.E. weder wirtschaftlich noch nebenbei zu bewerkstelligen ist, und einen *ganzen* Fachmann erfordert, der ich diesbezüglich nicht bin.

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.

ich glaube, hier stolperst wieder über "Import" vs "Datenschleuder".
Eine ZV-Software hält sich idealerweise an die BPD, die die Bank/das RZ für die Verarbeitung vorgesehen hat. Hier steht dann drin, wieviel die Bank akzeptiert. Die Software macht daraus dann passende Pakete - aber halt nur beim Import und nicht, wenn sie die Datei einfach nur übertragen soll. Eine so kleine Import-Beschränkung wäre mir auch nicht bekannt.

Ein Webportal kann eine ganz andere Schnittstelle bedienen, die muss mit FinTS nichts zu tun haben.

Übrigens gibt es auch EBICS-Webportale bei einigen genossenschaftlichen Banken, die eine gute Lösung für die gewünschte Verarbeitung darstellen könnten...

Gruß
Raimund

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.)

Das Beispiel von Dir ist zwar richtig, aber auch nur, weil hier die Spezifikation nur eine Angabe für den Geschäftsvorfall erlaubt, nicht für die Kontoart. Meist ist das Problem, dass sich die Vorhaltezeiten bei den Kontoarten unterscheiden (KK Konten meist kürzer, Sparkonten und andere Konten mit wenigen Bewegungen eher länger. Ansonsten ist es natürlich sinnvoll, sich an UPD /BPD zu halten, wenn man einen reibungslosen Ablauf haben möchte.


Grundsätzlich gebe ich Dir recht, was die Sinnhaftigkeit des Einsatzes von EBICS angeht. Wenn man nur Umsätze benötigt und Dateien versenden möchte, wäre das (wenn es nicht große Dateien sind) mit Kanonen auf Spatzen geschossen. Das fast immer aufgeführte Argument mit dem nicht unerheblichen Kostenfaktor wird mir immer ein Rätzel bleiben. Wenn ein Geschäftsmodell es nicht hergibt, dass man die Kosten für EBICS tragen kann, sollte man das Geschäftsmodell überdenken. Das bedeutet natürlich nicht, dass wenn ich Alternativen habe, die für meinen Bedarf sinnvoller sind, nicht die für mich wirtschaftlichere Variante nehme.



Auch wenn externe Komponenten einen beim Thema Fachlichkeit gut entlasten können, geht es nicht ohne speziellem KnowHow. Alleine dadurch, dass man für die zusätzliche Option "Banking" auch entsprechenden Support leisten können muss.... Bei solchen Dingen läuft man schnell Gefahr, sich völlig zu übernehmen.

Viele Grüße

Holger

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.