Verbesserungsvorschlag: MT940 Import

[#1]

Hallo,

Ich habe gerade ca. eine Stunde im Kanzlei Rechnungswesen mit dem MT940 Import gekämpft.
Am Ende stellte sich heraus, dass Datev nicht damit umgehen kann, dass in der MT940 Datei die IBAN statt der Kontonummer im Datenfeldfeld :25: steht. Die BIC davor ist aber ok.

Einige Banken erzeugen die Exports aber nun mal mit IBAN statt mit "alter" Kontonummer. So z.B. auch hier in einem Dokument der Deutschen Bank (von 2020) zum MT940 Format nachzulesen:

https://web.archive.org/web/20200618100100/https://deutschebank.nl/nl/docs/MT94042_EN.pdf

Vorschlag:

- Rechnungswesen sollte auch IBANs statt nur klassischen Kontonummern in MT940 Dateien erkennen und einfach verarbeiten, da dies eben viele Banken so machen.

- Die Fehlermeldung "Keine Kontoumsätze gefunden" etwas erweitern / spezifischer machen, z.B. Hinweis darauf, dass das Konto generell nicht in der Datei gefunden wurde, das die Datei nicht geparsed werden konnte, da das Format evtl. invalide ist oder ob zwar Buchungen gefunden wurden, aber nicht im gesuchten Zeitraum.

Als Zwischenlösung passe ich nun halt automatisch per Pythonscript meine MT940 Dateien an, es gibt ein pip package namens "kontocheck" welches die Konvertierung von IBAN -> Kontonummer durchführen kann.

[#2]

in der Formatbeschreibung MT940-Swift steht:

[#3]

---

@Timo_Witte schrieb:

Als Zwischenlösung passe ich nun halt automatisch per Pythonscript meine MT940 Dateien an, es gibt ein pip package namens "kontocheck" welches die Konvertierung von IBAN -> Kontonummer durchführen kann.

---

Dann wird das die Dauerlösung 👍. Ich habe der DATEV schon Feedback zum ISWL Bankkonverter gegeben, der das Gleiche macht aber eher in dumm. Da wird deine Lösung smarter sein. 

Eigentlich müsste der Import in DATEV auch nicht nur MT940 schaffen, sondern auch CSV und dann so schlau sein und selber in den CSVs ein Muster entdecken. 

MT940 ist zu 2025 abgekündigt und DATEV steckt aktuell alle Energie in die neue Cloud-Lösung. Da wird man am REWE nicht mehr rütteln. Man wird gesetzliche Änderungen einpflegen aber mehr im Großen und Ganzen auch nicht. 

[#4]

---

@metalposaunist  schrieb:

MT940 ist zu 2025 abgekündigt und DATEV steckt aktuell alle Energie in die neue Cloud-Lösung. Da wird man am REWE nicht mehr rütteln. Man wird gesetzliche Änderungen Einpflegen aber mehr im Großen und Ganzen auch nicht. 

---

Ja gut, das ist natürlich schade, dass Sie so einen kleinen Fix dann nicht mehr mit übernehmen, zumal Rewe ja die IBAN eh schon kennt und keine "Umrechnung" nötig wäre.

Da ich nur wenige Buchungen habe und kein Geld für Duo monatlich zahlen möchte, ist der Import per MT940 oder gerne auch nem anderen Format für mich die beste Lösung aktuell.

Meine Bank erlaubt es mir schon Dokumente und Metadaten mit den Buchungen im Konto zu verknüpfen und die auch wieder per API abzufragen. Aktuell haben wir noch kein DMS, aber sobald wir das haben, ist mein Plan eh ein kleines "syncscript" zu schreiben, welches automatisch monatlich die Daten aus der API inklusive Belegen und Metadaten importiert und dann per Datev API in REWE / Datev DMS bringt.

Hach ja XaaS, es muss ja jetzt alles in die Wolke.

[#5]

---

@Timo_Witte schrieb:

Ja gut, das ist natürlich schade, dass Sie so einen kleinen Fix dann nicht mehr mit übernehmen, zumal Rewe ja die IBAN eh schon kennt und keine "Umrechnung" nötig wäre.

---

Das ist nur meine reine Annahme. Für uns sind das immer "das kann ja nicht so schwer sein", bis DATEV uns erklärt, warum, wieso und weshalb das alles nicht so geht, wie man sich das ausdenkt. Die Programme sind nicht aus 2022 - und Dein Beispiel zeigt es ja schön, wie "schlau" das Programm mit den vorhandenen Informationen umgeht. 

---

@Timo_Witte schrieb:

welches automatisch monatlich die Daten aus der API inklusive Belegen und Metadaten importiert und dann per Datev API in REWE / Datev DMS bringt.

---

Berichtest Du vom Projekt? 🤓 Würde mich schon interessieren, ob das klappt und wenn ja, mit welchem Aufwand. Es liegen schon viele Informationen vor aber ob Dein kühner Plan so aufgeht, wie gedacht - bin sehr gespannt aber leider aufgrund meiner DATEV Erfahrung auch sehr skeptisch 😶. 

Daten in DATEV DMS abzulegen bzw. ein- und auszulesen per API klappt wohl mittlerweile, weil auch DRACOON und myDATEV senden auf dieser Schnittstelle basieren. Fragt sich dann, wie man dem REWE und den Buchungen automatisiert klar machen kann, dass der Beleg dazu in DMS liegt. Dazu braucht es ja einen Beleglink an der Buchung, die aktuell BEDI bei DUO lautet oder DDMA bei DMS (soweit ich weiß). 

Und dieser Beleglink / GUID kommt ja nicht aus der Bankingsoftware, oder? 

[#6]

---

@Timo_Witte schrieb:
[...]
Am Ende stellte sich heraus, dass Datev nicht damit umgehen kann, dass in der MT940 Datei die IBAN statt der Kontonummer im Datenfeldfeld :25: steht.
[...]

---

... also ich arbeite schon lange mit "Deutsche Bank"-Konten und mit MT940 und habe soeben nachgesehen, was in der Datei steht.

Bei mir steht (wie es sich gehört) :

:25:XXXXXXXX/YYYYYYYYY

X=BLZ

Y=Kontonummer

... und bei mir hat Kanzlei-REWE keine Probleme mit dem Kontoauszugsmanager und mit diesen Dateien

... allerdings werden diese und viele andere MT940-Dateien durch die Banking-Software erstellt und nicht von den Banken direkt geliefert

Wenn die "Deutsche Bank" auf direktem Weg "eine eigene Wurst brät", ist das ein Problem der "Deutschen Bank" und nicht der DATEV, meine ich

... die Banken sind Meister darin, Extrawürste zu braten

[#7]

---

MT940 ist zu 2025 abgekündigt und DATEV steckt aktuell alle Energie in die neue Cloud-Lösung. Da wird man am REWE nicht mehr rütteln. Man wird gesetzliche Änderungen einpflegen aber mehr im Großen und Ganzen auch nicht. 

---

Was bei DATEV perfekt funktioniert ist die Abkündigung von Programmen und die tatsächlich punktgenaue zeitliche Umsetzung. 

Wenigstens darauf kann sich der Anwender verlassen.

Diese zwanghafte Verlagerung der Anwendung in die Cloud stößt mir auf. Andere Anwendungen bestehen doch auch seit Jahrzehnten und werden nicht modernisiert und in die Wolke geschickt, insbesondere LODAS und Rechnungsschreibung.

[#8]

---

@martin65 schrieb:
[...]
Diese zwanghafte Verlagerung der Anwendung in die Cloud stößt mir auf. Andere Anwendungen bestehen doch auch seit Jahrzehnten und werden nicht modernisiert und in die Wolke geschickt, insbesondere LODAS und Rechnungsschreibung.
[...]

---

"to be or not to be" .... in the Cloud ... "that is the question"

LODAS war schon immer eine RZ-Anwendung

... keine Ahnung, ob eine RZ-Anwendung eine Cloud-Anwendung ist oder nicht ...

(... und das ist zur Abwechslung mal eine ganz ernst gemeinte Frage ...)

Übrigens, @martin65,  ich kann in Ihrem Post nicht erkennen, ob Sie nun LODAS und die Rechnungsschreibung lieber in der Cloud hätten oder nicht

Mir persönlich ist Software immer am liebsten, wenn sie nicht von mehreren anderen Programmen, Geräten und Online- und Offline-Diensten abhängig ist.

Ich erinnere mich z.B. noch gut an das Programm "Excel5.exe", das man auf einer 1,4 MB-Diskette mitnehmen und an jedem beliebigen anderen MSDOS-PC starten konnte und das auch schon alles rechnen konnte, was ich heute noch brauche.

[#9]

Ich hätte u.a. die beiden Programme gern in neu + schön + anwendbar.

Ob in der cloud oder im RZ ist mir egal.

Ich weiß nicht wie man "Cloud"-Anwendungen definiert.

Für mich ist alles, was nicht auf meinem eigenen Rechner gespeichert ist, eine Cloud-Anwendung. Deshalb wüsste ich auch nicht wohin LODAS wandern sollte. 

Eventuell bedeutet es aber, dass das Programm in der Cloud liegt und nicht im RZ. 

Habe ich heute keine Lust darüber weiter nachzudenken. Es wird uns schon jemand erklären.

[#10]

---

@martin65 schrieb:

Es wird uns schon jemand erklären.

---

Die LODAS "Rohdaten" liegen im RZ. Damit kann man aber ohne das Programm LODAS nichts anfangen. Und das Programm LODAS muss lokal installiert werden. Auf einem PC oder Server, auf den man sich aufschalten kann.

Cloud heißt: Weg von installierten Programmen, weil auch Office es Stand heute nur bis 2025 noch lokal installiert schafft. 

Was DATEV will? Word, Excel, PowerPoint im Web Bei der Lösung liegen nicht nur die Rohdaten in der Cloud sondern auch die Programme. Alles im Browser heutzutage möglich. Keine Installation von Office mehr nötig. Oder auch www.outlook.com - ebenfalls eine reine Webanwendung. Outlook installieren? Wozu? Nur DATEV braucht es für gewisse Funktionen noch. 

Lohn will DATEV mit Lohn online, so der Arbeitstitel in die Cloud hieven. DATEV plant aber keine 1:1 Umsetzung, sondern will auch gleich den Vorteil einbauen, dass man zusammen arbeiten kann bzw. andere auf die Daten zugreifen könnten, wenn sie denn müssten (Prüfer). 

🔙to topic! 

[#11]

---

Da ich nur wenige Buchungen habe und kein Geld für Duo monatlich zahlen möchte, ist der Import per MT940 oder gerne auch nem anderen Format für mich die beste Lösung aktuell.

.

---

Hallo, hast Du speetax versucht? Damit sollte funktionieren. Damit kannst Du für eine flat-rate viele Banken importieren. 

Liebe Grüße

Julian

[#12]

... wer nur wenige Buchungen hat und für DUO kein Geld ausgeben will, will erst Recht nicht noch mehr Geld für speetax ausgeben ...

... würde ich mal stark vermuten 😉 😎

[#13]

Daten in DATEV DMS abzulegen bzw. ein- und auszulesen per API klappt wohl mittlerweile, weil auch DRACOON und myDATEV senden auf dieser Schnittstelle basieren. Fragt sich dann, wie man dem REWE und den Buchungen automatisiert klar machen kann, dass der Beleg dazu in DMS liegt. Dazu braucht es ja einen Beleglink an der Buchung, die aktuell BEDI bei DUO lautet oder DDMA bei DMS (soweit ich weiß). 

Und dieser Beleglink / GUID kommt ja nicht aus der Bankingsoftware, oder? 

Ist an sich nicht so das Problem. Man läd den Beleg per DATEVConnect REST-API in DMS hoch (die b.t.w. für die on-premise Installation im Monat zusätzlich kostet und nicht einfach dabei ist), dabei bekommt man die GUID / sagt dem DMS eh in welchem Mandant und Bereich der Beleg im DMS abgelegt werden.
Die Antwort der API auf den Upload ist die GUID.

Über die REWE API kann man dann einen "Buchungsstapel" erzeugen und dort an einzelne "Buchungssätze"?! (ich bin komplett Fachfremd was Steuern angeht) einen Dokumentenlink setzen. Der Dokumentenlink ist die GUID im DMS.

Möchte man das nicht über API machen, kann man auch direkt die .NET Komponenten direkt instanzieren, aber da begibt man sich dann auf nicht sehr stabiles undokummentiertes Terrain.

Das Tool "ISWL Rechimport" macht das ja auch so z.B.

Am Ende sind es nur ein paar Datenbankeinträge im SQL Server, selbst die Dokumente selbst liegen als binary Payload im SQL Server in einer Tabelle..