Mit Release von gSales rev1055 am 24.9.2013 ist diese Dokument nicht länger gültig und wird durch die neue Anleitung https://gsales.zendesk.com/entries/27078246-Einrichtung-von-SEPA-Lastschriften-unter-gSales ersetzt.
Die in diesem Artikel beschriebene Funktionalität steht euch ab dem gSales 2 Release 1040 zur Verfügung. (Anleitung zum Update)
Beachtet bitte, dass sich die SEPA Funktionalität derzeit (Mai 2013) im Beta Stadium befindet. Prinzipiell wurde das generierte XML in unseren Tests nach dem Schema pain.008.002.02 validiert und sollte funktionieren.
Die Übergabe zu den Banken könen wir aber leider nicht endgültig testen und benötigen daher eure Rückmeldungen mit welcher Bank/Land es funktioniert und mit welcher nicht und ggf. wieso nicht (abweichende pain version, unzureichende Felder im XML, sonstige Fehler, etc). Wir sind hier aufgrund der unterschiedlichen Interpretationen des "Standards" auf eure Hilfe angewiesen und freuen uns über zahlreiches Feedback!
Testen solltet Ihr frühzeitig, am besten ab sofort, damit es am 1. Februar 2014 keine bösen Überraschungen gibt.
- Unter Administration > Konfiguration > Lastschriften folgende Werte (von euch) hinterlegen: "Kontoinhaber", "IBAN", "BIC", "Gläubiger-Identifikationsnummer"
-
Die Gläubiger-Identifikationsnummer wird von der Deutschen Bundesbank vergeben und kann unter https://extranet.bundesbank.de/scp/ beantragt werden.
-
Bei eurer Bank müsst ihr zusätzlich den SEPA Geschäftsvorfall für euer Konto freischalten lassen.
-
Für Kunden die am Lastschriftverfahren teilnehmen möchten müssen in den Stammdaten die benötigten Daten ergänzt werden. Unter dem Punkt Lastschriften bei "Kunde bearbeiten": "IBAN", "BIC" und "Mandat erteilt am". Als nächstes sicherstellen, dass die Checkbox "Lastschriften" aktivieren angeklickt ist.
Das Formularfeld "Mandat erteilt am" bezeichnet das Datum an dem der Kunde euch das Mandat (schriftlich) des Lastschrifteinzugs erteilt. Im Internet gibt es hierfür zahlreiche vorgefertigte Formulare. Google hilft: http://lmgtfy.com/?q=SEPA+Mandat+vorlage
Beachtet bitte, dass die "Mandatsreferenz" aus technischen Gründen aus der gSales Kunden-Id und dem Datum des abgegebenen Mandats zusammengesetzt wird und eurem Kunden erst nach der Unterzeichnungn mitgeteilt werden kann. Laut der Vorlage der deutschen Bundesbank ist dies in Ordnung. - Wie gewohnt Rechnungen schreiben, diese werden dann dem Lastenschriften-Pool hinzugefügt.
- Unter dem Punkt "Lastschriften" die Positionen markieren für die eine SEPA XML Datei erzeugt werden soll und "SEPA Datei herunterladen" unter "Aktion wählen..." auswählen. Eventuell fehlende Angaben in den Kundendaten werden euch hier in einem Fehlerfall angezeigt.
Kann diese Erweiterung auch aus der vorhandenen BLZ/KontoNr. eine SEPA-Lastschrift generieren oder die bestehenden umwandeln? Kann man entscheiden, ob DTAU oder SEPA genutzt wird, um den Umstellungszeitpunkt selbst zu bestimmen?
BIC wird wegfallen, da dies nur fuer den Uebergangszeitraum vorgesehen ist. Starmoney und Co. haben Umwandlungsroutinen, womit man DTAU-Dateien auf SEPA bringen kann. Besser waere es jedoch, einfach das in gSales zu erledigen, da es technisch unproblematisch ist.
Ich schaetze die Erweiterung derzeit so ein, dass neue Projekte sicherlich problemlos mit SEPA arbeiten koennen. Was ist aber mit den Alt-Projekten, die hunderte von Lastschriften enthalten. Da ist es kaum moeglich, diese zu einem Stichtag alle upzudaten, wenn ein manuelles Update ueberhaupt moeglich ist.
Hallo Marcus,
das aktuelle DTAUS Lastschriftverfahren gibt es natürlich noch und funktioniert parallel mit dem SEPA Verfahren. Bei Punkt 6. kann auch weiterhin eine DTAUS Datei generiert werden und bei ausreichenden Angaben eben auch die neue SEPA Datei.
Wird denn die SEPA-Datei bzw. der Datensatz nur erstellt, wenn IBAN und BIC auch vorhanden sind und die anderen alten DTAU-Daten uebersprungen? Die DTAU-Datei wird ja unabhaengig davon erstellt. Aus meiner Sicht wird das am Ende Chaos werden in bestehenden Installationen und kaum einer wird es schaffen, alle IBAN/BIC-Daten bis zum 01.02.14 nachzupflegen. D. h., man muss zwangslaeufig mit convertern arbeiten, das geht aber nur, wenn gSales das auch unterscheiden kann oder am besten selbst so einen converter anbietet.
An sich muss gSales einen Punkt bieten, wo man aus allen vorhandenen Lastschriftdaten einmal die fehlenden SEPA-Daten nachgeneriert und dann kann man generell zum Zeitpunkt x umstellen.
Hallo Marcus,
aus deinen Ausführungen ist ersichtlich das du dich noch nicht sonderlich viel mit SEPA beschäftigt hast. Ich empfehle dir hier unbedingt einen SEPA Workshop o.ä. bei deiner Bank zu besuchen. Aufgrund der Änderung des gesamten Lastschriftverfahrens und -prozesses kannst du die DTAUS Datei nicht einfach so konvertieren und dann einreichen wie gehabt. Bei SEPA gibt es jede Menge Regelungen die einen erhöhten Verwaltungsaufwand mit sich ziehen und beachtet werden müssen. Da ist das Nachtragen der IBAN das kleinste Problem, glaube mir.
Genau genommen lässt sich die IBAN auch nicht wirklich aus der Kontonummer und Bankleitzahl errechnen da unter anderem (!) die Kontonummer 10-Stellig sein muss und viele Banken aber vorneweg "nach Lust und Laune" auffüllen. Die Errechnung wird dadurch nicht korrekt durchgeführt und führt zu falschen Ergebnissen.
Ha, ha, ha, Julia, ich habe mich soviel mit SEPA beschaeftigt, dass es mir aus den Ohren rauskommt. Habe SEPA-Messen besucht und mir in einer 2 stuendigen Beratung bei der Sparkasse ganz ausfuehrlich die Verfahren und auch die vorhandene Software vorstellen lassen.
UND DESWEGEN, weiss ich auch, dass eine Konvertierung problemlos moeglich ist und in s-firm (Programm der Sparkasse) vorhanden ist, Starmoney macht es auch. Der Algorythmus fuer die Umrechnung ist sicherlich bei der Bundesbank zu beziehen. Im ernst, ich will nicht klugscheissen, aber lasst Euren Programmierer mal zu einer Banking-Beratung einer guten Sparkasse gehen. Die haben dort ein eigenes IT-Team, die sehr ausfuehrlich auf die Uebergangszeit und auch die Umwandlung eingehen. In s-firm kann ich voellig ohne Probleme DTAU-Dateien hochladen und in SEPA umwandeln lassen. Ich kann sogar Kundensaetze anlegen und die neuen IBAN/BIC speichern fuer die zukuenftige Verwendung und noch besser, die Mandats-Datumsangaben koennen automatisch berechnet werden, so dass es keine Probleme beim Einreichen mit den Fristen gibt.
Ich habe mich ausfuehrlich mit dem Thema SEPA beschaeftigt und mache mir echte Sorgen, ob gSales das schafft. Das Thema ist wirklich nicht leicht und die reine SEPA-Erweiterung sicherlich eher eine vergleichsweise kleine Sache. Wirklich spannend wird es erst, wenn man sich bei Bestandprojekten mit dem Wechsel beschaeftigt. Wie kriege ich alle Daten in gSales, wann stelle ich um, kann ich parallel beides betreiben? Es kann an sich nur einen Loesungsansatz geben: Zum Zeitpunkt x alle fehlenden IBAN/BIC-Daten generieren und anschliessend keine DTAU mehr nutzen.
Vielleicht noch ein Hinweis (auch nur als Anregung gemeint): Die meisten gSales Bestandskunden werden die Mandate zu einem festen Zeitpunkt einholen und mehr oder weniger dann zum Zeitpunkt x auch alle Rückläufer erhalten. Es waere gut, wenn man allen Bestandskunden einfach ein Datum fuer die Mandatserteilung zuweisen koennte. Die meisten werden vermutlich keine Lust haben, dass direkt in PhpMyAdmin zu machen. Die alten Mandate haben zwar Bestand, aber ich vermute mal, dass die meisten kaum manuell die alten Mandatserteilungs-Daten raussuchen und im Bestand fuer alle Kunden nachtragen wollen.
Hallo Julia,
wie sehen die Pläne in Bezug auf die SPEA Vorankündigungen aus? Das halte ich auch für eine sehr wichtige Funktion. g*Sales müsste im Optimalfall per Cronjob o.ä. die Vorankündigungen automatisiert verschicken können und bei jeder Änderung einer Serienrechnung eines Lastschrift-Kunden müsste automatisch eine aktualisierte Vorankündigung verschickt werden.
Ich sehe in den Vorankündigungen den mitunter größten Verwaltungsaufwand.
Außerdem bringt das reine einreichen der Lastschrift per SEPA ja auch noch nichts. Die Lastschrift müsste ganz anders als die DTAUS Lastschriften gehandhabt werden. SEPA Lastschriften müssten schon X Tage vor Fälligkeit in der Lastschriften Liste erscheinen und entsprechend mit Fälligkeitstermin in der XML Datei stehen. Denn damit die Lastschrift zur Fälligkeit (was ja vermutlich der Termin ist, der dem Kunden vorangekündigt wird) beim Kunden auch eingezogen wird, muss die Lastschrift mindestens 5-6 Tage (je nach Bank) vor dieser Fälligkeit eingereicht werden.
Daher ist die Funktion, wie ihr sie derzeit umgesetzt habt zwar ein guter Anfang, reicht aber keinesfalls aus um mit g*Sales SEPA zu machen :-)
Hallo Sebastian,
richtig. Derzeit sind 7 Tage fest hinterlegt da diese beim Ersteinzug eingehalten werden müssen. Danach sind es nur noch 5 Tage die wir allerdings derzeit nicht berücksichtigen da wir nicht zwischen Erst- und Folgeeinzug unterscheiden.
Bedeutet, am 1. de Monats wird eine Rechnung erstellt. Die SEPA-Datei eingereicht und 7 Tage später werden die Beträge eingezogen.
Wir streben derzeit an die Pre-Notification über den Rechnungsabschlusstext abzuhandeln. Dieser würde dann sinngemäß lauten, dass der Betrag in 7 Tagen / Datum abgebucht wird. Dies ist zwar entgegen der empfohlenen 14-Tage - kann allerdings über das Mandat mit dem Zahlungspflichtigen so vereinbart werden und man schlägt dadurch 2 Fliegen mit einer Klappe. Einerseits die 7 Tage Wartefrist und gleichzeitig die Benachrichtigung.
gSales kann leider nicht 14 Tage vorher ermitteln welche Positionen abgerechnet werden da durch die Warteschlange jederzeit etwas zusätzlich hinzukommen und die Abrechnung dann um 14 Tage "blockieren" würde.
Wir sind hier auf der Suche nach einer eher pragmatischen Lösung welche nicht noch mehr Schritte als bisher erfodert. Sind aber wie ich finde auf einem sehr guten Weg.
Hallo Julia,
das mit den festen 7 Tagen halte ich so auch für sinnvoll. Eine Folgelastschrift ist es laut der Definition, die ich gehört habe, nur dann, wenn der Betrag gleich ist. D.h. man müsste dann pro Serienrechnung und nicht pro Kunde feststellen, was eine Folgelastschrift ist. Das ist den Aufwand nicht Wert.
Aber es sind soweit ich weiß Bankarbeitstage oder noch genauer TARGET2-Arbeitstage (siehe z.B.: http://www.vdb.de/sepa-verfahren.aspx - wobei hier was von 5 Tagen bei der Erstlastschrift steht).
Somit ist das doch nochmal etwas komplizierter. Es müsste flexibel für jeden Termin der genaue Lastschrifttermin berechnet werden!
Die Pre-Notification über den Rechnungsabschlusstext klingt durchaus sinnvoll. Bitte aber auch bedenken, dass alleine der von dir geschriebene Text nicht reicht. Es muss auch die Gläubiger-ID und ich die Mandatsreferenz in der Pre-Notification auftauchen. Es sind also schon ein paar neue Variablen dafür nötig.
Die 14 Tage darf man ja reduzieren und an den Stellen, wo ich bisher mit SEPA zu tu hatte, machen die meisten das auch auf 7 Tage.
Fazit: Klingt gut, was ihr vorhabt und ich hoffe, dass die neuen Variablen für den Rechnungsabschlusstext zeitnah mit einem Update nachgereicht werden und, dass es eine Lösung für das TARGET2-Arbeitstage Problem geben wird.
Hier einmal ein Auszug aus dem Steuerprogramm quicken:
SEPA-Fähigkeit von Quicken 2014
Ab wann kann ich mit Quicken 2014 SEPA-Lastschriften verwalten?
SEPA-Lastschriften sind mit dem Start von Quicken 2014 im April noch nicht verfügbar.
Das Feature wird voraussichtlich im Herbst (genauer können wir den Zeitpunkt im Moment noch nicht bestimmen) als kostenloses Servicepack für Quicken 2014 nachgeliefert.
Bereits jetzt werden in der Datenübernahme aus der Vorversion automatisch IBAN und BIC für alle vorhandenen Empfängerbankverbindungen ergänzt, so dass eine händische Nacharbeit nicht erforderlich ist.
Ich halte eine automatische Konvertierungsmoeglichkeit von alter BLZ/Kontonr. nach wie vor fuer absolut notwendig und vor allen Dingen wirklich prioritär. Ansonsten können alle Bestandsnutzer mit Lastschrift gSales kaum mehr nutzen, da eine Stichtagsumstellung nicht moeglich ist.
Als Ergänzung (ich war gestern auf so einem Workshop):
Es ist zwingend erforderlich, dass zwischen Folge- und Erstlastschrift unterschieden wird. Eine Erstlastschrift ist immer dann, wenn aufgrund des erteilten Mandates das erste mal etwas eingezogen wird (entweder bei einem Neukunden oder bei der Umstellung auf SEPA), eine Folgelastschrift dementsprechend bei nachfolgenden Lastschriften aufgrund des gleichen Mandates/mit der gleichen Mandatsreferenz (wobei es der Information gestern nach nicht wichtig ist, ob diese die gleiche Höhe haben). Was aber wichtig ist: ohne dass es auf dem betreffenden Konto keine Erstlastschrift mit der betreffenden Mandatsreferenz gab sind keine Folgelastschriften möglich (es geht also nicht, der Einfachheit halber alles als Folgelastschriften zu kennzeichnen, genausowenig wie mehrfache Erstlastschriften mit der gleichen Referenz möglich sind)
Das mit der Umstellung IBAN/BIC sehe ich persönlich nicht ganz so dramatisch, zumindestens meine Sparkasse bietet da ein Tool an, was auch via CSV größere Mengen konvertieren kann. Das mit einem kleinen Script direkt aus der gsales2-DB zu ziehen, in dem Tool zu verarbeiten und dann wieder reinzuschreiben wäre zumindestens für mich machbar. Die Konvertierung hat allerdings den Ausführungen gestern nach Grenzen bei einigen Banken, da diese teilweise Fillialbezogene Bankleitzahlen haben. Da man die betreffende Filiale im Normalfall eher nicht mitgespeichert hat kann in solchen Fällen nicht automatisch konvertiert werden.
Sehr wichtig wäre aber eine saubere Unterstützung der PRE-Notification-Geschichte (da geht z.B. nicht, dass man z.B. schreibt "7 Bankarbeitstage nach Rechnungslegung" -> das Datum muss konkret benannt sein)
Hier geht es weiter http://support.gsales.de/hc/de/articles/202105643-Einrichtung-von-SEPA-Lastschriften-unter-gSales