SEPA Lastschrift Problem

Hallo,
wir arbeiten auf den Objekten der 2.6 sind technisch auf 2009 - SQL Datenbank. Aus bestimmten Gründen die ich jetzt nicht weiter definieren möchte die aber völlig OK sind müssen wir die SEPA Anbindung selbst zu Fuß machen. Das ist so und nicht änderbar.
Bei DTAUS war es bisher wie folgt. Wir hatten einen Kunden, der hatte 3 Rechnungen über 100 € und eine Gutschrift über 50 €. Natürlich konnte man diese Gutschrift vorher ausgleichen, haben wir aber nicht, wir haben sie einfach im Lastschrifteinzug mit drin gelassen und alles war gut. Solange der Rechnungsbetrag gesamt für den Kunden > als der Gutschriftsbetrag war, war dies OK.
Soweit früher.

An dem Lastschrifteinzug selbst habe ich jetzt zunächst nicht soviel geändert. Natürlich die neuen Felder etc. aber grundsätzlich lese ich das als CSV Datei aus und mein Kollege wandelt mir die CSV Datei per Bizztalk in das eigentliche SEPA format um. Der kommt jetzt und sagt - Moment - da sind auch Gutschriftszeilen drin. Du darfst mir Zeilenmäßig nur positive Werte auslesen - also nur Rechnungsbeträge in der Zeile. Ist das so? Können wir diesen kleinen Verrechnungstrick nicht mehr anwenden? Unsere Fibu ist relativ verzweifelt. Kann mir jemand der den Luxus der Standard SEPA Objekte hat dazu einen heißen Tipp geben?

Die einzige alternative die mir einfallen würde wäre eine Überweisung und eine Lastschriftauslesung zu erstellen.

Danke
Sandra

Hallo,

wie das funktioniert, sollte euch eure Bank sagen können, bzw. im Internet gibt zu dem Thema sicherlich eine Unmenge an Informationen.

Woher bekommt dein Kollege den IBAN und Swift- Code, ich hab mir von nem Banker sagen lassen, das man das nicht unbedingt so einfach ausrechnen kann. Wie geht Ihr mit den Mandaten um, den geänderten Beschreibungslängen, und der Ankündigung einer Lastschrift,...


Gruß, Fiddi

Hallo,

diese Verrechnungsmethode ist auch im SEPA Zahlungsverkehr möglich. Die Fehlerbeschreibung klingt eher nach "falschem" zusammensortieren der Posten (genaugenommen Buchblattzeilen) die zusammengefasst eine Banktransaktion ergeben. Die Zusammenfassung erfolgt über Kontonr. (Debitor), Mandatsart, Fälligkeitsdatum (SEPA), und Mandat Einzugsart. Irgendwo da in der Ecke scheint das Problem zu sein.

LG Jens

Hallo Jens,
es geht nicht um die Zusammenfassung sondern die Einzelposten. So wie ich Pain 008.003.02 verstanden habe gibt man da genauso einzel Posten mit, wie früher in der DTAUS Datei nur mit mehr Informationen bzw. eben auch IBAN und Swift. D.h. ich orientiere mich weiterhin an den Diskettenposten. Und da sind halt eben auch Gutschriften drin. Diese gebe ich dann als CSV mit allen gewünschten Informationen aus und mein Kollege macht dann die Konvertierung in das XML Format und fällt dann bei den Gutschriften auf die Nase. Der Rechnungsbetrag für den Debitor selbst bleibt natürlich als Rechnungsbetrag stehen. Aber es ist der "Einzelposten" der uns Kummer bereitet - nicht die Summe.

@Fiddi die Bank stellt in Abrede dass es bei DTAUS funktioniert hat. Hat es aber. Zumindest die letzten 13 Jahre.
Außerdem liefere ich meinem Kollegen alles mit. Wenn ich sage ich habe SEPA entwickelt meine ich das auch so - komplett mit Mandatsverwaltung etc. Zum 01.02.2014 suche ich dann vermutlich eine neue Stelle - aber das sage ich dann noch rechtzeitig!

Gruß
Sandra

Hallo Sandra,

ich habe einfach nur in den Quelltext des Reports geschaut der eine SEPA Lastschrift erzeugt... Ich probiers mal aus und melde mich.

LG Jens

Hallo Sandra,

ich habe die Erstellung einer SEPA-Lastschriftdatei mit dem Akquinet ZV ausprobiert und bin etwas irritiert:

1. Sobald eine Gutschriftszeile dabei ist bekommt man eine völlig irreführende Fehlermeldung:

130802_SEPA_Gutschrift.jpg

2. Entscheidet man sich für "Nur Rechnungen" und erstellt die Lastschriftdatei, sieht es so aus als ob es alles Einzeltransaktionen sind. Die Gegenbuchungszeilen zum Bankkonto sind auch jeweils zur einzelnen Rechnungszeile.

Die Datei die erstellt wurde sagt das sie pain.008.002.02 ist. Nunja. Ich sehe da Probleme auf uns zukommen... ich würde das wohl so ändern das die Einzüge saldiert zusammengefasst werden, als eine Transaktion in die XML-Datei, und was halt geht in <RmtInf><Ustrd> in den 140 Zeichen unterbringen.
Noch besser wäre es natürlich wenn Akquinet eine vernünftige Lösung bereitstellt.

LG Jens

Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.

Entscheidet man sich für "Nur Rechnungen" und erstellt die Lastschriftdatei, sieht es so aus als ob es alles Einzeltransaktionen sind. Die Gegenbuchungszeilen zum Bankkonto sind auch jeweils zur einzelnen Rechnungszeile.

Meintest du wirklich eine Zahlung pro Rechnungszeile oder pro Debitorenposten?

Gruß, Fiddi

Hallo Fiddi,

öhm... latürnich nicht... pro Buchblattzeile. Da diese normalerweise mit "Ausgleich-mit Belegnr." verbunden sind dann auch pro Debitorenposten.

LG Jens

...verbunden sind dann auch pro Debitorenposten

O.K. dann bin ich beruhigt

Gruß, Fiddi

Hallo Jens,
Vielen, vielen Dank! Das hilft doch schon mal weiter. Ich glaube nicht Akquinet da viel tun kann. Wie gesagt wir bekommen ja den Fehler beim Umwandeln in die XML Datei nach ISO Standard. Aber die Lösung mit der "Summe" ist gut. Das werde ich hier intern besprechen und dann so umsetzten. Ist halt eine Menge mehr Arbeit für mich aber mei - ist halt so.
Wäre halt nett gewesen wenn man das vorher gewusst hätte, aber vielen dank für das Testen. Das hat mir super geholfen.

Gruß
Sandra

Hallo Sandra,

das mit der Summe ist aber nix neues... so arbeitet DTAUS eigentlich, DTAZV auch (ähnlich). Deswegen gibt es ja "Anzahl Posten für Avis"... wenn absehbar ist das der Verwendungszweck nicht mehr reicht, das Zielbankkonto aber das gleiche ist. Um Transaktionskosten zu sparen werden diese zu einer Summe zusammengefasst und sind dann eine "Payment Order" (zu sehen in den Zahlungszeilen, Table 5001903). Diese Verdichtung bringt natürlich auch Probleme mit sich, wie z.B. Z1-Meldungen (Gutschriften nicht erlaubt), aber dieses Thema ist ja jetzt erledigt. Ansonsten sehe ich keinen wirklichen Grund die einzelnen ausgeglichenen Positionen in Banktransaktionen umzuwandeln.

LG Jens

Hallo Sandra,

ich habe die Erstellung einer SEPA-Lastschriftdatei mit dem Akquinet ZV ausprobiert und bin etwas irritiert:

1. Sobald eine Gutschriftszeile dabei ist bekommt man eine völlig irreführende Fehlermeldung:(...)
2. Entscheidet man sich für "Nur Rechnungen" und erstellt die Lastschriftdatei, sieht es so aus als ob es alles Einzeltransaktionen sind. Die Gegenbuchungszeilen zum Bankkonto sind auch jeweils zur einzelnen Rechnungszeile.

Die Datei die erstellt wurde sagt das sie pain.008.002.02 ist. Nunja. Ich sehe da Probleme auf uns zukommen... ich würde das wohl so ändern das die Einzüge saldiert zusammengefasst werden, als eine Transaktion in die XML-Datei, und was halt geht in <RmtInf><Ustrd> in den 140 Zeichen unterbringen.
Noch besser wäre es natürlich wenn Akquinet eine vernünftige Lösung bereitstellt.

LG Jens

Mir haben unsere Anwender berichtet, dass bei DTAUS das Standardverhalten des Systems so war, dass Einzüge saldiert zusammengefasst wurden, und nur der Endbetrag relevant war. Sprich, wenn eine oder mehrere Gutschriften in den Offenen Posten waren wurden diese mit den Rechnungen saldiert und der Einzug funktionierte solange die Rechnungsbeträge > Gutschriftsbeträge.
Dies scheint ja nun mit SEPA nicht mehr zu gehen, da sobald eine Gutschriftszeile enthalten ist, immer o.a. Fehler erscheint.
Müssen wir dies nun aufwändig Anpassen lassen, wenn wir das alte Systemverhalten wiederhaben wollen?

Danke für die Rückmeldung.

Hallo,

Müssen wir dies nun aufwändig Anpassen lassen, wenn wir das alte Systemverhalten wiederhaben wollen?

Gute Frage. Nach meinem dafürhalten leider ja...

LG Jens

Hallo,

so einfach scheint mir das mit dem saldieren nicht mehr zu sein, da du ja u.U. dem Kunden mitteilen musst wann du welchen Betrag einziehen willst. Das wird schon schwierig, wenn du saldieren möchtest. Außerdem könnte es da noch ein paar Fallstricke in der SEPA- Implementierung deiner Bank geben, die u.U. auch noch bestimmte Anforderungen an den Inhalt der Datei haben könnte (nur ein Buchungsdatum pro Datei, keine Mischung von Zahlungsarten,...)

Gruß, Fiddi

Halo Fiddi,

guter Hinweis. Das liesse sich durch entsprechendes gruppieren beim erstellen der Lastschriftdatei (wahrscheinlich aber besser bei Erstellung des Vorschlags) machen. Der üblichere (? naja, häufigere) Fall ist das man bezahlt... dort ist mit SEPA aber leider das gleiche Problem, das Gutschriften im Korb zu einer komischen Fehlermeldung führen. Gepoolt wird soweit ich das gesehen habe schon... nur Gutschriften müssen halt wieder beigebracht werden.

LG Jens

Hallo,
so einfach scheint mir das mit dem saldieren nicht mehr zu sein, da du ja u.U. dem Kunden mitteilen musst wann du welchen Betrag einziehen willst.

Das stimmt, aber ohne "u.U." , denn SEPA-Pre-Notification ist verbindlich (14 Tage vorher, wenn nichts anderes vereinbart wurde). Wenn die nicht erfolgt , und das Konto nicht gedeckt ist, wird es "u.U." teuer für den Gläubiger wegen Gebühren für Rücklastschriften, oder eventuelle Überziehungszinsen beim Zahler, die der Gläubiger dann erstatten muss, wenn er das versäumt hat.
https://www.volksbank-ludwigsburg.de/fi ... cation.pdf
http://www.haufe.de/finance/buchfuehrun ... 87000.html

@jglathe,

Das liesse sich durch entsprechendes gruppieren beim erstellen der Lastschriftdatei

Wenn ich mich richtig erinnere, kannst du dir das sparen, weil der Zahlungsverkehr das schon macht

Gruß, Fiddi

@jglathe,

Das liesse sich durch entsprechendes gruppieren beim erstellen der Lastschriftdatei

Wenn ich mich richtig erinnere, kannst du dir das sparen, weil der Zahlungsverkehr das schon macht

Gruß, Fiddi

Klärt mich bitte noch einmal auf: Ich habe es noch nicht ganz genau verstanden.

Was passiert nun wenn ich eine Rechnung (z.B 20 Euro) und eine Gutschrift (z.B. 10 Euro) bei einem Kunden habe und ich dann per Fälligkeit und SEPA-Lastschrift den Betrag einziehen will.

Zieht er dann nicht 10 Euro ein sondern 20 Euro ein? Und wie regele ich das dann mit der Gutschrift?
Oder habe ich euch hier falsch verstanden?

mfg,
winfy

Hallo,

das kommt darauf an, was du für einen SEPA- Typ verwendest, wie du dem Kunden mitteilst, was du wann gedenkst einzuziehen. Wenn du die Prenotifikation mit der Rechnung machst, musst du das an dem Tag mit dem Betrag auch tun.
Dann kommen die Banken mit ihren Spezialitäten und SEPA- Versionen noch hinzu.
Es ist besser die Finger von solchen Verrechnungen zu lassen. Gutschrift extra auszahlen und fertig.

Gruß, Fiddi

Hallo,

vielleicht ein bisschen spät, aber wir haben jetzt erst die Sepa-Updates eingespielt und alle Einstellungen neu vorgenommen: Es wird je Einzugsdatum und Debitor auch verrechnet. Wenn man nicht täglich (wie die Banken sich das vorstellen) ziehen will, bleibt nur die Zahlungsbedingungen zu ändern, um möglichst viele Posten zu einem Einzug saldieren bzw. Gutschriften verrechnen zu können, also z.B. LW+14T für wöchentlichen Einzug + Frist Prenotifikation. So haben wir das gelöst.

Gruß kebor