In S-Firm wird nur angeboten die Datei auf Diskette zu exportieren; die Einstellung für HBCI ist ausgegraut.

Transkript

1 S-Firm/StarMoney/StarMoney Business mehrere Stapel über HBCI Problembeschreibung: Die oben genannten Produkte der Star Finanz GmbH, Hamburg nachfolgend Banking Software genannt, erlauben in der aktuellen Version nicht das Versenden von SEPA Aufträgen mit mehreren Stapeln 1 innerhalb einer physischen Datei über HBCI. In S-Firm wird nur angeboten die Datei auf Diskette zu exportieren; die Einstellung für HBCI ist ausgegraut. Nach unseren Informationen behaupten mittlerweile auch Electronic Banking Berater der Banken und Sparkassen, eine SEPA XML Datei mit mehreren Stapeln sei unzulässig. Wir möchten mit diesem Dokument alle betroffenen Parteien aufklären und unseren Kunden damit bestmöglichen Service bieten. Dennoch stellen wir klar, dass die von KARTHAGO 2000/Judikat erzeugten Dateien mit mehreren Stapeln gültig sind und dem aktuellen Standard entsprechen. Die Weitergabe dieses Dokuments an beteiligte externe Dritte (z.b. Electronic Banking Berater) ist hiermit gestattet. aktueller Status ( ): Nach Aussagen der Star Finanz GmbH wird aktuell an den Problem gearbeitet. Zitat: Zu StarMoney Business: Derzeit ist es in der Tat so, dass StarMoney (Business) beim Import einer XML-Datei mit mehreren logischen Dateien, nur die erste erkennt und importiert. Mit dem kommenden ServicePack Mitte Dezember 2013 werden wir entsprechende Anpassungen beim Import vornehmen, die u. a. auch XML-Dateien mit mehreren logischen Dateien korrekt erkennt und entsprechend alle Sammelaufträge importiert. Zu SFirm: Das importieren von xml-dateien mit mehreren logischen Dateien und die anschließende Ausgabe funktioniert jetzt schon. Das direkte Versenden (ohne Import) per HBCI ist mit dem nächsten PL (9.12. ) möglich.

2 mögliche Workarounds: Die hier beschriebenen Workarounds basieren auf Erfahrungen und Kundenaussagen. Die UTS GmbH übernimmt keinerlei Haftung, dass die hier beschriebenen Problemlösungen in jeder Konstellation funktionieren. Um sicherzugehen, sprechen Sie bitte Ihren Electronic Banking Berater und den Kundensupport der jeweilig eingesetzten Banking Software an. Eine endgültige Lösung kann nur die Anpassung der Banking Software an den jeweils gültigen Standard sein. Dennoch möchten wir Sie unterstützen und einige Problemlösungen vorstellen: Workaround 1 (nur ein Stapel je Datei): Trennen Sie beim SEPA/DTA in KARTHAGO 2000/Judikat nach einzelnen Stapeln. (Wir unterstellen bei dieser Vorgehensweise, dass Sie keine Einmallastschriften, nicht Option COR1 und nur ein Bankkonto je Objekt verwenden.)

3 1. Dabei filtern Sie die auszuführenden Zahlungsträger nach Objektnummer und Fälligkeitsdatum.

4 2. Beim SEPA/DTA Erstellen erzeugen Sie bitte zuerst Erst/Einmallastschriften. 3. Danach rufen Sie mit der gleichen Selektion den Vorgang noch mal für Folgelastschriften auf. Diese Punkte wiederholen Sie bitte für jedes Objekt und Fälligkeitsdatum einzeln. Sie erhalten dadurch SEPA XML Dateien mit jeweils nur einem Stapel. Diese Dateien können Sie einzeln über Ihre Banking Software versenden. Workaround 2 (Umstellung EBICS): Nach unseren Informationen treten die genannten Probleme nur in Verbindung mit HBCI auf. Durch Umstellung auf EBICS kann das Problem umgangen werden. Hinweis: In der Regel werden für EBICS von den Banken/Sparkassen höhere Gebühren verlangt. Workaround 3 (Importieren der Zahlungen): Nutzen Sie nicht die Funktion Versenden der Banking Software, sondern importieren Sie die Zahlungen und starten danach die Übertragung zur Bank. Hinweis: Eventuell müssen Sie Konten in der Banking Software hinterlegen.

5 Workaround 4 (Online Portal): Verschiedene Banken unterstützen das Versenden von SEPA XML Dateien über das Online Portal (Web Zugang). weitere Informationen: Wie verweisen hierzu auf Ihren Electronic Banking Berater sowie den Hersteller der entsprechenden Banking Software. Fall Sie neue (in diesen Dokument nicht beschriebene) Erkenntnisse haben, so bitten wir Sie im Interesser aller Kunden, diese uns zukommen zu lassen. Nutzen Sie dazu bitte die adresse support@uts.de

6 Anhang 1 (technische Beschreibung): Wir verweisen dabei auf das DFÜ Abkommen Anlage 3: Spezifikation der Datenformate, welches für alle Banken im Kunde2Bank Verhältnis verbindlich ist. Aktuell gültig ist die Version 2.7 vom Hier wird auf Seite 25 genau spezifiziert, dass maximal Stapel innerhalb einer physischen Datei wiederholt werden dürfen. Eine weitere Definition ist zu finden auf Seite 39 (SCT) bzw. Seite 66 (SDD): Definition Satz von Angaben, z. B. Einreicherkonto, Fälligkeitsdatum, welcher für alle Einzeltransaktionen gilt. Die Payment Information entspricht einem logischen Sammler innerhalb einer physischen Datei. XML-Tag <PmtInf> Kardinalität [1..unbounded] *1 Stapel: Eine physische SEPA XML Datei ist intern in sog. Payment Information Blöcke (= Stapel) aufgeteilt. Die Trennung erfolgt u.a. nach Auftraggeberkonto, Fälligkeitsdatum, Kennzeichen Erst-, Folge-, Einmal, letzte Lastschrift, sowie einigen weiteren Steuerungskennzeichen. Im Gegensatz zur bisherigen DTA Datei werden Überweisungen und Lastschriften in getrennten physischen Dateien verarbeitet. Die folgenden Begriffe werden als Synonym für Stapel verwendet: - Sammler - logische Datei (in Anlehnung an das DTA Verfahren) - Payment Information Block Der Hinweis Die Payment Information entspricht einem logischen Sammler innerhalb einer physischen Datei. ist in Anlehnung des DTA Verfahrens so, zu verstehen, dass ein Payment Information Block (SEPA Begrifflichkeit) einer logischen Datei (DTA Begrifflichkeit) entspricht. Dies schließt aber keinesfalls aus, dass mehrere Payment Information Blöcke innerhalb einer physischen Datei enthalten sein dürfen. Die technische Bezeichnung innerhalb der SEPA XML Datei lautet <PmtInf>.

7 Dies wird zusätzlich bestätigt, da der Hinweis auf Seite 40 (SCT) und auch in der englischen Version auf Seite 68 (SDD) nicht enthalten ist. In jeglicher technischen Beschreibung wird ebenfalls davon ausgegangen, dass unbegrenzt viele Stapel innerhalb einer physischen Datei enthalten sein dürfen: Kardinalität [1..unbounded] bedeutet: Mindestens 1 Stapel muss enthalten sein, es dürfen bis zu unbegrenzt viele enthalten sein. Auszug der Schemadefinition (XSD) für Lastschriften in der Version 2.7 (pain xsd) <xs:complextype name="customerdirectdebitinitiationv02"> <xs:sequence> <xs:element name="grphdr" type="groupheadersdd"/> <xs:element name="pmtinf" type="paymentinstructioninformationsdd" maxoccurs="unbounded"/> </xs:sequence> </xs:complextype> Auch hier wird klar definiert, dass (technisch gesehen) unbegrenzt (unbounded) viele Stapel (hier PmtInf) innerhalb einer physischen Datei enthalten sein dürfen. Die Einschränkung auf Seite 25 sollte dennoch Beachtung finden. Diese dient dazu, dass Systeme nicht mit großen Datenmengen unnötig belastet werden. Fazit: Die von KARTHAGO 2000/Judikat erzeugten SEPA XML Dateien entsprechen dem aktuell gültigen Standard. Der hier angesprochene Standard ist für alle Banken/Sparkassen verbindlich. Eventuelle Probleme in der Weiterverarbeitung der aus KARTHAGO 2000/Judikat erzeugten Dateien liegen nicht im Verantwortungsbereich der UTS.