Wie ich bereits im Thread um die fälligen Aufträge im Ausgangskorb schrieb,
kam es bei mir zu einem heftigen Fehler.

Ich hatte zwar x 2 erneut gesendet, da lt. Ausgangskorb die Aufträge noch aktiv waren,
ABER die Lastschriften wurden bis heute z.T. bis zu 7 x eingezogen.
Kurios daran ist, dass die Anzahl der Einzüge von 0 mal, bis eben hin zu den 7 malen variieren
und dass es sich lt. der Auszüge, zum Teil um "Euro-Lastschriften" handelt, zum anderen Teil
um "Euro-Eil-Lastschriften".
Als ich die Lastschriften nach diesem Fehler jeweils einzeln neu terminiert habe, habe ich genau darauf geachtet,
welche Form der LS jeweils angegeben war. Und bis auf 4 von über 170 war die Eillastschrift eingegeben (die 4 standen noch auf BasisLS)

Gesendet wurde am Mo. 03.02. ca. 20 Uhr.
Zuvor (03.02. 00.15 Uhr ) hatte ich versucht zu senden, dieses scheiterte durch die Fehlermeldung bei der 2. PIN Eingabe
( hatte ich hier: http://www.onlinebanking-forum…ht=nicziko beschrieben)

Die ersten wenigen Eingänge auf den Konten waren vom 05-02, am 06. dann viele, am Fr. 07. keine.
Ich begann mit den Rücküberweisungen
Jetzt Montag und Dienstag kamen jedoch weitere Eingänge an. Und ich weiß von Kunden, dass sie auch für Mittwoch (12-02) noch fällige Abbuchen lt. derer Programme erwarten..
Hat irgendjemand eine Idee wie es zu diesem Desaster hat kommen können?
Ich versuche Erstattungen, Widersprüche..neue Zahlungseingänge zu koordinieren und den Überblick zu behalten.

Und dann steht der nächste 1. schon wieder ins Haus und ich traue mich gar nicht die fälligen LS zu senden..solange der Fehler nicht geklärt wurde.

Zunächst unbedingt das gestrige Online-Update ausführen!

Hallo Nicziko, mir ging es ähnlich.
zwar nicht mit Dauerlastschriften
sondern mit einer Sammellastschrift mit 86 Positionen.
Das Programm hängte sich beim senden auf. Im Ausgangskorb
blieb kurioserweise ein Teil der Liste "aktiv" zurück.
Ich sendete sie nochmal. Das war ein Fehler. Wie sich
Gestern herrausstellte, nur mit Hilfe der Bank, da ich niergendwo mehr im Programm
sehen kann, was gesendet wurde; dass diese Lastschriften die aktiv im Ausgangskorb lagen
bereits versendet waren. Können von der Bank auch nicht mehr
zurück geholt werden, da die Bank sie sofort, obwohl der termin erst am 15.2.
Ist, weiter geleitet hat.
jetzt muss ich alle anrufen, damit sie die Gelder nicht gebührenpflichtig
zurück beladten.
Alles was vorher reibungslos funktionierte, klappt mit diesen neuen Udate nicht mehr.

Ist das bei anderen Bank-Softwaren auch so?

Liebe Grüße Sabine

Nein, Nicziko hat ganz tief ins Klo gegriffen. Er hatte eine nicht freigegebene Version erhalten, die einen Bug hatte, bei dem Dauerlastschriften nach der Ausführung nie aus dem Ausgangskorb verschwunden sind. Das ist umso ärgerlicher, da über das Vorliegen dieser Version exakt mit der Info zu dem Fehler informiert wurde und die Datei auch nur über einen Testlink abrufbar war.
Bei Dir ist es eine ganz normale Situation, wenn es zu einem Fehler kommt, die in dieser Form auch mit IZV Lastschriften vorgekommen sind. An der Stelle hat man systembedingt bis zu einem bestimmten Zeitpunkt (und bankabhängig) mehr Möglichkeiten zu erfahren was mit den Aufträgen passiert ist als früher. Verpasst man den Zeitpunkt, kommt man ohne Information der Bank dann aber gar nicht weiter. Zu deinem Fall im Detail:


HBCI ist ein Dialogbasiertes Verfahren. Sprich das Banksystem gibt immer eine Meldung zurück, was mit den Aufträgen passiert ist. Stürzt die Anwendung/das System, die Verbindung während der Übertragung ab, kann der Status nicht ermittelt (es liegen ja keine Antworten vor) werden und die Aufträge verbleiben im Ausgangskorb.

Ab jetzt muss man wissen, wie SEPA Lastschriften unter HBCI funktionieren (bitte nicht den Sinn dahinter fragen/ die die Spezifikation gebaut haben, legen den Rechtsrahmen so aus, dass man so vorgehen muss…)
Das erste was man schauen sollte
Rückmeldungen am Auftrag
Auftrag öffnen und auf Rückmeldungen klicken – wird in dem Fall aber vermutlich nichts drinn stehen
Umsätze abrufen
Hat die Bank etwas gebucht und liefert diese Informationen ggf. sofort als vorgemerkten Umsatz oder als Buchung

Auftragsbestand abrufen
SEPA Lastschriften sind in HBCI bankverwaltete Aufträge und landen (je nachdem wann diese eingereicht wurden) in einer Terminverwaltung. Deren Bestand kann man abrufen/ändern/löschen /wenn die Bank das unterstützt). Alle zurückgemeldeten Aufträge landen unterhalb des Kontos in der Ansicht Lastschriften (auch die eingereichten Dauerlastschriften!). Aufträge mit einem O im Symbol sind die Aufträge, die die Bank zurück gemeldet hat und demnach in der Terminverwaltung führt.

Bank anrufen und nachfragen
Wenn wir von SEPA Vorlaufzeiten sprechen, sprechen wir von zwei Vorlaufzeiten
1. Vorlaufzeit der Bank, bei der ich die Lastschrift einreiche
2. Vorlaufzeit für die Vorlage der Lastschrift bei der Bank des Schuldners
In der Praxis bedeuten die 6 Tage die immer im Raum stehen eigentlich, dass es nie 6 Kalendertage sein können, sondern immer mehr sind. 1 Bankarbeitstag für die entgegennehmende Bank um den Auftrag zu verarbeiten und 5 europäische Bankarbeitstage (TARGET2 Tage) vor Fälligkeit, als Vorlage bei der Bank des Schuldners. Da die Woche nur maximal 5 Arbeitstage hat, reichen keine 6 Kalendetage.
Die Vorlaufzeit 2 bedeutet auch: Die Lastschrift muss 5 TARGET Tage vorher bei der Bank des Schuldners sein und ist damit aus den Systemen der Bank des Einreichers „verschwunden“.
Daher wurde die Lastschrift bei Dir auch direkt weitergeleitet um eben diese Fristen einzuhalten.

Wenn das Geschäftsmodell es erlaubt, würde ich mich daher bei der Einreichung der Lastschriften immer anders organisieren.
Bei Dauerlastschriften würde ich die Option „benutzerdefinierter Versand wählen“ und in den Einstellungen 3 oder 4 Tage Vorlauf drauf schlagen. Oder ich würde z.B. bei monatlichen Lastschriften zum 01. Diese immer am 15 versenden. Mit dem Vorgehen, darf ich das Versanddatum auch mal verpassen, ohne dass die Vorlaufzeit gerissen wird und die Aufträge landen in der Terminverwaltung und man hat viel mehr Möglichkeiten Dinge noch zu klären oder zu korrigieren

@ Nicziko
Schau mal am Konto bei den Lastschriften (nicht Dauerlastschriften) rein. Dort findest Du alle Lastschriften, die Du versendet hast. Die Ansicht kannst Du Drucken, oder exportieren und dann z.B. in Excel einlesen, so dass Du eine Grundlage hast, mit der Du siehst, was auf Dich zukommen könnte und was Du schon abhaken kannst.

Viele Grüße

Holger

Haben die hier betroffenen Banken denn keine Doppeleinreichungskontrolle?

Das frag ich mich beim Lesen der entsprechenden Threads auch schon länger. Gerade Fiducia ist ja was Überweisungen betrifft extremst pingelig, was Doppeleinreichung betrifft. Dort hilft es nicht mal, den VZ1 zu modifizieren (wie z.B. bei den Sparkassen). Da sind zwei Zahlungen gleicher Höhe ans gleiche Empfängerkonto NICHT möglich. Trifft das NUR auf UW und nicht auf LS zu?

Doch, eine minimale Änderung im Verwendungszweck umgeht die Doppelverarbeitungsprüfung. Das funktioniert allerdings nur bei SEPA-Zahlungen - nicht bei IZV.

Ah! Gut zu wissen, dass das jetzt anders ist.
Meine Erfahrungen stammten aus dem IZV. Da war garnix zu machen...

Kann es denn sein, dass bei mir einige Aufträge eben doch schon verarbeitet wurden, obwohl das Versenden durch den Fehler bei der 2. Pin Eingabe gescheitert ist?
Das könnte dann die unterschiedliche Zahl der LS erklären.

Auf das Nachsehen unter "Lastschriften" hätte ich auch selber kommen können, aber ich sehe grad den Wald vor lauter Bäumen nicht..

@MSA Unter der 4.x Version war es nicht möglich doppelt zu versenden. Selbst wenn ein Auftrag im A-Korb verblieben ist( dann allerdings auch nie aktiv), bekam man die Meldung, dass dieser Auftrag bereits verarbeitet sei.

Ja, schon klar. Ich meinte aber die Bankrechnerseitige Doppel-EINREICHUNGS-Kontrolle, die sowas garnicht erst annimmt. Aber das ist von Institut zu Institut unterschiedlich ausgebildet.

Hast Du während der Übertragung 2 x die Pin eingeben müssen? Dann in der Tat. Es gibt Vorgänge, bei denen technisch der eine Dialog abgeschlossen wurde und ein zweiter anschliessend gestartet wird. Dann wären die Aufträge im ersten Dialog komplett abgearbeitet worden und nur die Aufträge im zweiten Dialog gescheitert. Sowas kann man in der 5er sehr gut im Dialogfenster sehen. Dort steht immer welcher Auftrag (Lastschriftsammler, Umsatzabruf......) gerade versendet wird und wie der Status des Auftrags ist.


Es ist wie MSA beschrieben hat. Weder die 4er, noch die 5er haben eine eigene Doppeleinreicherkontrolle. Die passiert immer auf Seiten der Bank. Auch bei der 5er stehen fehlerhafte Aufträge nach dem Versand inaktiv im Ausgangskorb. Das Handling an der Stelle hat sich nicht geändert. Lediglich bei dieser einen nie freigegebenen und nier veröffentlichten Version war es anders. Da blieben erfolgreich versendete Aufträge weiter aktiv im Ausgangskorb.
Alles andere ist wie bei der 4er, nur das der Status von einem Dialog im Dialogfenster jetzt auch für den Laien deutlich zu erkennen ist. Wenn da alles grün ist, hat die Bank auch gemeldet, dass Sie alles erfolgreich war.

Viele Grüße

Holger

Ich bin immer davon ausgegangen, dass mit doppelter PIN-Eingabe eine Doppelzeichnung gemeint ist und hatte mich schon gewundert.... Offenbar ist aber die wiederholte Eingabe der PIN eines Einzelzeichnungsberechtigten gemeint gewesen???

OK, dann ist den Leuten aber auch nicht zu helfen. Wer ohne Rückfrage bei der Bank zum selben Auftrag ein zweites mal seinen PIN und/oder eine TAN hergibt der würde auch Verträge blind unterschreiben und dagegen ist kein Kraut gewachsen

Eben. Drum bin ich ohne groß Nachzudenken von vorneherein von Doppelzeichnung ausgegangen. Aber jetzt klingt das so, als wäre es anders...
Man könnte ja jetzt einen Schutz des Bankkunden fordern: Wenn der Bankrechner die gleiche PIN innerhalb sagen wir 10min mehrfach erhält, dann werden alle Aufträge on Hold gelegt und ein Bankbeamter muß den Kunden anrufen und die tatsächlichen Wünsche abklären. Wär doch auch für <BtchBookg>falso schön. Man könnte doch eben nochmal telfonisch nachfragen, ob das wirklich so gemeint war

msa, ganz einfach, man könnte einfach die Gedanken des Kunden lesen und ihm alles abnehmen, damit er sich mit garnichts mehr beschäftigen braucht

Hmm, da wäre dann evtl. eine Kooperation mit der NSA hilfreich...

Sorry, aber wo ist denn das Problem zu einem und dem selben Auftrag eine PIN einzugeben? Passiert doch nichts!
Davon abgesehen ist das hier überhaupt nicht gemeint.
Innerhalb eines Dialoges können mehrere HBCI Dialoge mit mehreren HBCI Nachrichten geführt werden. Innerhalb eines HBCI Dialoges wird einmal eine PIN abgefragt.

Wenn ein bankverwalteter terminierter Auftrag eingereicht wird, erfolgt diese Einreichung im HBCI Dialog 1. Wenn es entsprechend eingestellt ist, wird anschließend der Bestand der eingereichten Aufträge abgerufen, dieser Abruf wird in einem HBCI Dialog 2 geführt. Dazu ist eine zweite PIN notwendig.

Nur eine PIN ein zweites Mal einzugeben führt zu keiner Fehleingabe. Wichtig ist aber eben sich das Übertragungsfenster anzuschauen, da sieht man welcher Auftrag gerade abgearbeitet wird und man sieht auch welchen Status dieser Auftrag entsprechend erhält. Und diese Information ist mit der 5er inzwischen so dargestellt, dass das auch ein Laie verstehen kann.

Viele Grüße

Holger

Holger, das war jetzt auf das Problem der mehrfachen Einreichung des selben Auftrags bezogen. Aber dieser Thread hier ist mittlerweile auch nicht mehr ganz einfach. Worum geht es inzwischen eigentlich hier?

Es geht hier in meinem Fall darum, dass beim Senden einer Sammellastschrift mit 68 Lastschriften eine Störung auftrat.
Das Senden wurde unterbrochen. Danach befanden sich noch 42 Lastschriften dieser Sammellastschrift im Ausgangskorb. Ihre Kennzeichnung war noch "aktiv"
Da dachte ich, die Liste ist nur zum Teil durchgegangen, weil ja noch aktiv. Daraufhin habe ich den Rest nochmal geschickt.

Wir sind ein gemeinnütziger Verein wir können uns nicht leisten, auf unser Geld weiter 4 Wochen zu warten. Leider ging die erste Liste komplett durch. Nun hab ich 42 Doppellastschriften.
Wie können die Lastschriften aktiv im Ausgangskob liegen, obwohl sie verarbeitet wurden?

LG

Naja,
die SW hat im ersten Durchgang die Aufträge an die Bank gesendet - die Bank bucht - und dann sendet die Bank für jeden Auftrag auch eine entsprechende Rückmeldung an die SW. Wenn diese durch einen
Verbindungsabbruch oder sonstige Störungen die O.K. Meldung nicht bekommt, dann die SW den Auftrag nicht als erledigt kennzeichnen, weil sie davon nichts weiß. Jetzt liegt es an der SW zu erkennen, das der Auftrag zwar gesendet wurde - aber KEINE Rückmeldung vorliegt - weder positiv noch negativ - der Auftrag also eigentlich zu prüfen wäre und auf aktiv stehen sollte... wenn aber - wie im geschilderten Fall die SW das nicht richtig abfängt, hat der Anwender ein Problem...
Daher gilt die Empfehlung - unabhängig von der SW - bei jeglichen "komischen" Abbrüchen und/oder Fehlermeldungen beim Auftragsversand die Protokolle/Statusmeldungen prüfen und/oder die Umsätze zu aktualiesieren - auch abhängig vom "Buchungsverhalten" der Bank - wer gerne telefoniert ruft auch die Bank an ,-)

Od