(in Arbeit)

Hier geht es um ein häufiges Problem, das beim nachträglichen Anzeigen von Sammelaufträgen auftreten kann und wie man es vermeiden kann.

Vorab ein praktischer Tipp: Ich nutze die Druckfunktion über einen PDF-Drucker. So kann ich sämtliche Drucke speichern, spare Papier und kann auch nachträglich meine Unterlagen drucken, sollte ich diese je wieder benötigen. Ein freier und auch für Firmen kostenloser PDF-Drucker ist z.B. Free-PDF. Läuft selbst unter Win8 problemlos.

Technisch läuft die sogenannte Sammleraufsplittung innerhalb einer Software im Groben so ab:
1. Eine Buchungs- oder Zahlungsverkehrssoftware erstellt Buchungen als Sammler, überträgt diese und “merkt” sich, wie sich der Sammler zusammensetzt.
2. Die Bank verarbeitet die Aufträge und liefert dann in den Umsatzdaten die Informationen mit, dass es sich bei der Buchung um einen Sammelauftrag handelt.
3. Die Buchungs- oder Zahlungsverkehrssoftware erwartet diese Information und “erkennt” den Sammler in den Umsatzdaten. Sie sucht in der eigenen Datenbank nach den dazu passenden Aufträgen und ordnet die Einzelaufträge dem Sammelumsatz zu.
Stimmen nun “Erwartung” und Buchung nicht überein, kann die ZV-Software die Sammelbuchung nicht aufgesplittet anzeigen.

Es kann hier eine ganze Reihe von Ursachen geben.

Sammler im Browserbanking (Onlinebanking ohne FinTS/HBCI)
Sammler können im Onlinebanking nicht nachträglich aufgesplittet werden. (ein Fakt!). Deshalb unbedingt nach dem Senden die (PDF-?)Druckfunktion nutzen. Oder eine Zahlungsverkehrssoftware, die wie oben arbeitet.

Sammler unvollständig angenommen:
Werden fehlerhafte Datensätze übertragen, kann es vorkommen, dass der Bankserver die fehlerhaften Teil-Aufträge gar nicht erst akzeptiert und den Sammler nur teilweise annimmt. Im Browserbanking erhält man eine Postkorbnachricht. Verwendet man eine  ZV-Software und erkennt diese nicht die abgelehnten Datensätze, weil sie mit den Hinweisen des Bankservers nicht klar kommt, kann sie später auch nicht die Sammler “vernünftig” aufsplitten. Wie das FinTS/HBCI-Protokoll die fehlerhaften Aufträge bei GAD-Banken auswirft, können Sie hier lesen. Es ist ein Manko der Software, wenn die Protokolle nicht ausgewertet werden. Die Banken “sehen” die abgelehnten Aufträge nicht mal, wenn also hier seitens der einreichenden Software schlampig gearbeitet wird (nicht nur meine Meinung), dann wird die spätere Fehlerbearbeitung für die Nutzer  komplex. Besonders ärgerlich finde ich, dass wichtige Verarbeitungshinweise versteckt werden.

Lastschriftsammler: Buchungsdatum “unerwartet”
SEPA-Lastschriften werden – je nach Bankeinstellung und Übertragungsverfahren – nicht unbedingt an einem festgelegten Datum verarbeitet. Die meisten Banken haben auch eine mögliche Änderung des Fälligkeitstermins mit ihren einreichenden Kunden vereinbart, so dass sich die Fälligkeit verschieben kann, wenn z.B. die Übertragung nicht mehr rechtzeitig möglich war. Ist die ZV-Software unflexibel programmiert, erwartet sie die Verarbeitung fix am Datum x und erkennt nicht, dass sie am Tag x+1 gebucht wurde.
Umgekehrt genauso: Es gibt Banken, die die Gutschrift eingereichter Lastschriften üblicherweise am Übertragungszeitpunkt vornehmen. Das hat den Vorteil, dass die Buchung sofort an den Umsatzdaten erkennbar und verfügbar wird, also vor der Fälligkeit. Die Wertstellung (Valuta) ist dann trotzdem der Fälligkeitstermin, der Buchungstermin kann aber eine ganze Woche davor liegen, z.B. bei erstmalige Basislastschriften 5 Tage vorher. Diese Einstellung kann bei GAD-Banken kontoindividuell umgestellt werden, so dass die Buchung und Fälligkeit zusammenliegen.

Umsatzdaten werden nicht als Sammler erkannt
Je nach Vorgehen der ZV-Software kann es sein, dass eine Buchung nicht als Sammelbuchung erkannt wird, z.B. weil der Textfilter der Software einen Fehler hat. Sie “übersieht” dann die Verarbeitung. Einige Programme können “mit der Nase draufgestoßen” werden, es können manuell vorgemerkte Buchungen einem Sammelumsatz zugeordnet werden.

externe Sammelbuchungen (XML-Dateien)
Werden Buchungsdateien, z.B. aus einer Vereinsverwaltung oder Buchhaltungssoftware oder auch Gehaltsbuchungen vom Steuerberater also von “außerhalb” verarbeitet, dann “schauen” sich nicht alle ZV-Programme die enthaltenen Buchungen an und können entsprechend nachträglich nicht “wissen”, wie sich der Sammler zusammen setzte. Genauso ist es, wenn die Software selbst die Daten nicht übertragen hat.
Meist heißt es in den Menüs sinngemäß: “Datei zur Übertragung einlesen” statt “Zahlungsaufträge importierten”.

Im gleichen Netz, aber die Programme teilen sich nicht die gleiche Datenbank? Dann weiß der eine Rechner vom anderen auch nichts, genausowenig, wenn mehrere verschiedene Programme verwendet werden.


Lösungsansätze

Nutzen Sie eine netzwerkfähige Software? Dann sorgen Sie am besten dafür, dass die Programme sich die gleichen Datenbanken teilen, das vermeidet Probleme.

Sie nutzen mobile Rechner und einen Büro-Computer? Überlegen Sie entweder eine Backup-Strategie (der neuere spendet die Daten dem anderen Rechner) oder Sie installieren die Software gleich auf einem USB-Stick oder anderm mobile Datenträger (das geht technisch für die mobile-Version der VR-NetWorld Software, für Profi cash und auch für windata/GLS eBank). Bei Gelegenheit schreibe ich dazu mal etwas mehr…

Sammler als Anlage zum Kontoauszug aufsplitten
Die Banken können die Sammlerverarbeitung nachträglich als Anlage zu den Kontoauszügen aufsplitten. Das kann kostenpflichtig sein, da es nicht unerhebliche Kosten verursacht (alleine schon Papierkosten und ökologisch ist es auch nicht).

Sammleraufsplittung für Steuerberater und EBICS
Die Bank kann die Verarbeitung von Umsätzen so steuern, dass die im Sammler enthaltenen  Einzelumsatzinformationen den Service-Rechenzentralen (wie die DATEV) und/oder über EBICS zur Verfügung gestellt werden können. In Richtung FinTS/HBCI und Onlinebanking ist dies nicht möglich und meines Erachtens auch nicht sinnvoll – dann könnte ja gleich einzeln gebucht werden (oder per deaktiviertem Batchbooking, siehe unten). Die “Aufdröselung” passiert dann direkt im Rechenzentrum.


Lesen Sie hier mehr über Sammelaufträge und die Verarbeitung:
Sammler übertragen, einzeln buchen: Batchbooking deaktivieren etc.

Wenn in GLS eBank/Windata nicht erkennbar ist, welcher Fehler bei einer Datenübertragung aufgetreten ist, könnte es an der abgeschalteten Info liegen. Die Fehlerursache lässt sich auch meistens noch nachträglich finden.

Unter Statistik, Übertragene Zahlungen kann man die gesendeten Buchungen kontrollieren. Siehe erstes Bild. Hier habe ich die “Erweiterten Informationen” deaktiviert. Dies sollte aber nicht der Standard sein.

“Übertragen” meint hier nur, dass die Datenübertragung stattgefunden hat – nicht, dass die Bank die Buchungen verarbeiten konnte (oder wollte).

Informationen_Windata_fehlen_01

Setzt man bei “Erweiterte Informationen” den Haken, sieht man die Meldungen des Rechenzentrums. (0020) ist beruhigend, heisst diese Meldung doch, dass der Auftrag verarbeitet wurde.

Informationen_Windata_fehlen_02

Hier finden Sie eine allgemeine Anleitung zur Fehlerinterpretation in FinTS/HBCI.

Bei fehlerhaften Aufträgen, die der Server direkt erkannt hat (z.B. eine fehlerhafte BIC), gibt der Server direkt eine Fehlermeldung aus und nimmt den fehlerhaften Teilauftrag nicht an. Und hier ist auch der Fehlergrund direkt sichtbar. Dies ist abhängig von der Bank und ihren Einstellungen. siehe auch: teilausgeführte Sammler.

#sammlerfehler

Welche FinTS/HBCI-Sammler nicht ausgeführt wurden, sieht man bei GAD-Banken in der  HBCI-Rückmeldung. Zumindest diese Information muss die Software anzeigen, idealerweise kann sie diese aufbereitet auswerten.

Im Text steht dann beispielsweise
“Sammler unvollständig verarbeitet. 1 Posten fehlerhaft.”

Die Fehlerstelle wird durch den Code 3290 gekennzeichnet, rückgemeldet wird die Nummer des Auftrags im Sammler.

Die Fehlerursache wird durch den anderen Code 3260 näher spezifiziert. Hier sollte auch mehr zur Ursache im Klartext zu finden sein.

Ein Beispiel aus einem typischen HBCI-Protokoll:

HIRMG:3:2+3060::Bitte beachten Sie die enthaltenen Warnungen/Hinweise. (TRE) HIRMS:4:2:3+3260::Sammler unvollstaendig verarbeitet. 1 Posten fehlerhaft. (BSC)+3290::Der BIC ist für diese Zahlungsart nicht zulässig:3

hier ein Beispiel mit zwei falschen Kontonummern…
HIRMS:4:2:3+3260::Sammler unvollstaendig verarbeitet. 2 Posten fehlerhaft. (BSC)
+3290::Die Probebuchung war fehlerhaft.:4
+3290::Die Probebuchung war fehlerhaft.:6 

Beim BIC-Fehler ist also der Auftrag Nummer 3 betroffen, bei den Probebuchungen Auftrag 4 und 6. Hier habe ich für den Test nicht existente Kontonummern meiner eigenen Bank genommen.

So sehen Sie die Fehlermeldung in Windata /GLS eBank: Statistik

Eine leistungfähige Zahlungsverkehrssoftware sucht sich die fehlerhaften Datensätze selbst heraus, kennzeichnet diese und bietet eine Änderung an. Bei schönen Lösungen könnte ich mir sogar eine Fehlerhilfe vorstellen, z.B. bei einer falschen BIC der Hinweis, wo man z.B. die BIC-Liste der Bundesbank finden kann (dem sogenannten SCL-Directory).

Wenn ein Programm die Rückmeldungen nicht auswertbar liefern sollte, sprechen Sie mit dem Hersteller der Software! Dies ist eine “Mussfunktion”, wenn man mit Sammlern vernünftig arbeiten möchte.

Die Bank selbst sieht diese abgewiesenen Buchungen nicht! Es bringt also nichts, hier nach Fehlern zu fragen, es ist höchstens sinnvoll, nach den verarbeiteten Daten suchen zu lassen. Dies sieht anders aus, wenn der Sammler vollständig angenommen wurde und anschließend erst in der weiteren Verarbeitung ein Fehler festgestellt wird. Dies können – zumindest aktuell – nur MitarbeiterInnen der Bank einsehen (und auch nur Menschen, die eine entsprechende Berechtigung im Banksystem besitzen).

Lesen Sie hier: Wo finde ich das HBCI-Protokoll