Sehr geehrte Community,
wir nutzen in unserem Unternehmen zur Bankbearbeitung das Programm SFIRM.
Ich hab jetzt angefangen den Import der Bankkontoumsätze per .sta durchzuführen.
Die Übernahme und die Funktion der Buchungsvorschläge erzeugen funktioniert problemlos.
Mein Problem besteht nun darin das der Verwendungszweck nach Übernahme aus dem SFIRM durch die EREF bzw. andere Felder "aufgeblasen" wird und im Buchungstext in Datev nun viele unnötige Daten stehen. Ich versuche dem Problem mit Lerndateieinträge entgegenzuwirken, wollte jedoch Fragen ob es evtl. eine einfachere Möglichkeit gibt.
Im Anhang noch zwei Bilder um das Problem zu beschreiben. Bild 1 zeigt den Bankauszug und als Verwendungszweck wird nur das wichtige bzw. das benötigte angezeigt (in SFIRM). Bild 2 zeigt dann den fertigen Buchungssatz als Import mit den Daten die überhaupt nicht benötigt werden (EREF bzw. der Zusatz vor dem Verwendungszweck "SVWZ+".
Kann man nun irgendwie einstellen das "SVWZ+" nicht davor gestellt wird und das der EREF nicht mit übergeben wird?
Über jegliche Hilfe bin ich sehr dankbar.
Mit freundlichen Grüßen
Ben Katzschner
DATEV macht es sich wie üblich recht einfach. Das Datenformat MT940 ist recht einfach gestrickt und muss mit diversen Neuerungen klarkommen, mit der Zeit wurden daher in den Kennziffern Unterkategorien eingeführt die DATEV nur halbherzig umgesetzt hat.
DATEV parst die .sta und schreibt den jeweiligen Inhalt in die DATEV Datenbank (mit gewissen Anpassungen wie z. B. die Geschäftsvorfallnummer und legt dann gleich die Beschreibung bei). S-FIRM wertet die Daten (nichts anderes bekommt S-FIRM vom Kreditinstitut) anders aus und stellt es ansprechender dar.
DATEV wird auch keine Zeit mehr in eine Renovierung des Zahlungsverkehrs stecken, was wir haben muss reichen, dafür wurde in ReWe ja auch sehr viel Aufwand mit der Lerndatei betrieben um diese Defizite auszugleichen. Der Aufwand für den Nutzer diese Lerndatei zu pflegen interessiert nicht.
MT940-Dateien sind 'reine' ASCII-Dateien, die man mit jedem beliebigen Editor bearbeiten könnte .... wenn man wollte
... mit "Suchen + Ersetzen" könnte man unerwünschten 'Müll' entfernen.
... aber wer will das schon ... außer mir ... ? 😄
Naja jeden Tag nach SFIRM Export die Datei noch "korrigieren" kann ja nicht unbedingt die Lösung sein (auch wenn es grundsätzlich eine Lösung wäre) 🙂
Folgende Lösung bevorzuge ich bei OPOS-Buchhaltungen:
- für wiederkehrende Zahlungen, welche nicht debitorisch/kreditorisch gebucht werden, sind Lerndateien angelegt, über die der gewünschte Buchungstext eingesteuert wird
- offene Posten werden mit dem gewünschten Buchungstext eingebucht
- Bei der Zahlungsbuchung (Ausgleich des offenen Postens) benötige ich in der Regel keinen Buchungstext. Allerdings lasse ich mir vom System den Auftraggebernamen im Buchungstext vorbelegen (nicht hilfreich, aber "schöner" als ohne Text und besser als der Verwendungszweck). Die Einstellung kann wie folgt vorgenommen werden:
Danke für Ihren Beitrag,
bei den meisten Zahlungen funktioniert das mit der Lerndatei ganz gut bzw. lasse ich mir auch den Auftraggebernamen in den Buchungstext schreiben.
Das oben geschilderte Problem tritt halt leider bei Zahlungen eines Zahlungsdienstleister auf.
D.h. wir verkaufen in einer unserer Außenstellen Ware und diese wird mit EC bezahlt.
2-3 Tage später erhalten wir das Geld mit den oben geschilderten Verwendungszwecken. Wenn der Verwendungszweck der mir im SFIRM angezeigt wird 1:1 so übergeben würde, dann hätte ich kein Problem, jedoch wird halt noch unsäglich sinnloses Zeug angehangen wodurch es selbst mit Lerndatei nicht immer eindeutig klappt.
@BenKatzschner schrieb:Naja jeden Tag nach SFIRM Export die Datei noch "korrigieren" kann ja nicht unbedingt die Lösung sein (auch wenn es grundsätzlich eine Lösung wäre) 🙂
... man erhält auch an vielen anderen Stellen nicht immer DIE Lösung (auch nicht immer öfter) 😉
... der Spatz in der Hand ist mir (manchmal) lieber als die Taube auf dem Dach ...
... ja nach Vorgehensweise und Einrichtung würde sich der manuelle 'Aufwand des Korrigierens' auf das Ziehen und Ablegen der STA-Datei auf eine Script-Datei oder auf eine EXE-Datei beschränken, körperlich keine schwere Arbeit 😎
... besser wäre es natürlich, dem Kontoauszugsmanager ein wenig mehr KI 'einzutrichtern'
In Bank Online sind mir noch ein paar andere Sachen aufgefallen.
Im Vergleich zu einem Export vom Online Banking.
Es wird alles in Großbuchstaben geändert.
Teilweise werden Leerzeichen entfernt.
Beides ein Informationsverlust.
Gerade die beide in Kombination macht es recht schwer einen Namen noch automatisiert zu verarbeiten.
Ich sehe in den Paar von Ihnen markierten Zeichen keinen Grund warum die Lerndatei, dass nicht wegbügeln können sollte. 🤔 Vielleicht bin ich auch einfach nur blind und frage mich warum man SFIRM im Einsatz hat. 🤔
@jjunker schrieb:Ich sehe in den Paar von Ihnen markierten Zeichen keinen Grund warum die Lerndatei, dass nicht wegbügeln können sollte. 🤔 Vielleicht bin ich auch einfach nur blind und frage mich warum man SFIRM im Einsatz hat. 🤔
Wenn man sich die Daten genau ansieht weiß man warum, es handelt sich um einen Sack voll EC Zahlungen die von einem Zahlungsdienstleister zusammengefasst werden. Um diese Daten mit den Kassendaten abstimmen zu können braucht man dies. Das mit DATEV Lerndatei richtig zuzuordnen, vor allem damit OPOS oder Sachkonten OP damit klarkommt, ist schon recht aufwändig. Könnte bei einem detaillierterem Parsen schon einfacher gehen.
Warum nimmt man S-FIRM? Ganz einfach weil DATEV Zahlungsverkehr vieles nicht kann was S-Firm bietet. Wer es braucht nimmt S-FIRM. Wer Auslandsüberweisungen auszuführen hat weiß wovon gesprochen wird.
DATEV kann viel, einiges gut, einiges notdürftig und einiges schlecht, aber bei Weitem nicht alles.
"DATEV kann viel, einiges gut, einiges notdürftig und einiges schlecht, aber bei Weitem nicht alles." Unterschreibe ich sofort. Mir war auf den ersten Blick nicht klar, dass es sich um eine Sammelzahlung von EC Umsätzen handelt. Vor dem Hintergrund leuchtet, es ein. 🤗