Ich bekomme von einem Mandanten Bankkontoumsätze in CSV-Format. Diese habe ich über eine ASCII-Weiterverarbeitungsdatei zum Einlesen in Rewe weiterverarbeitet.
Leider klappt der Import nicht Es wird immer nur ein Buchungssatz übernommen. Den Aufbau der ASCII Datei habe ich mehrfach sorgfältig geprüft.
Woran kann das liegen? Leider sagt Rewe ja nur: ein Buchungsvorschlag erstellt. Warum er die anderen 270 nicht erstellt hat, weiß ich nicht. Es gibt keine Fehlermeldung.
Hat jemand eine Idee?
Gelöst! Gehe zu Lösung.
... nur mal ein "Schuss in's Blaue" ....
... stecken in der ASCII-Datei nach jeder Zeile evtl. falsche Steuerzeichen, z.B. EOF-Codes oder Ähnliches ?
Falls ja, .... entfernen und nur durch <CR> (Carriage Return) ersetzen
Ich würde an Ihrer Stelle mal die ASCII-Datei genau in einem Editor (Notepad.exe oder notpad++ oder noch besser mit einem HEX-Editor) anschauen
.... aber wie gesagt, das ist nur eine spontane Idee (ohne Gewähr, wie beim Lotto )
Viele Grüße
Michael Vogtsburger
Ich bin für jeden eventuellen Hinweis dankbar!
Im Notepad hatte ich schon geschaut und keine Auffälligkeiten gefunden.
Vielleicht hilft der HEX-Editor...
... ein Öffnen der CSV-Datei mit Excel und "speichern unter" (... anderem Namen) bereinigt vielleicht auch unsichtbare Zeichen oder Steuer-Codes.
Vielleicht stößt der Import auch auf (angebliche) Leerzeilen
... oder der Zeichensatz enthält ungültige Zeichen.
Notepad++ kann die Zeichen-Codierung anzeigen und auch bei Bedarf konvertieren.
Vielleicht stecken in den Buchungstexten Zeichen aus anderen Codepages, ausländische Zeichen etc.
Dieses Thema war schon immer eine Baustelle (ASCII, ANSI, UTF-8, UNICODE etc)
Ich gehe davon aus, dass Ihnen die Formatbeschreibung der ASCII-Weiterverarbeitungsdatei ( Dok.-Nr.: 9226961) bekannt ist und dass die Datei die Voraussetzungen erfüllt, z.B. die Anzahl der Felder und andere Vorgaben (z.B. "wenn ein Kann-Feld nicht gefüllt ist, muss für dieses Feld trotzdem ein Semikolon eingefügt werden")
Gruß
Michael Vogtsburger
update:
ein Semikolon zuviel, zu wenig oder an der falschen Stelle kann den korrekten Import verhindern
... ein Öffnen der CSV-Datei mit Excel und "speichern unter" (... anderem Namen) bereinigt vielleicht auch unsichtbare Zeichen oder Steuer-Codes.
Vielleicht stößt der Import auch auf (angebliche) Leerzeilen
... oder der Zeichensatz enthält ungültige Zeichen.
Notepad++ kann die Zeichen-Codierung anzeigen und auch bei Bedarf konvertieren.
Vielleicht stecken in den Buchungstexten Zeichen aus anderen Codepages, ausländische Zeichen etc.
Dieses Thema war schon immer eine Baustelle (ASCII, ANSI, UTF-8, UNICODE etc)
Ich gehe davon aus, dass Ihnen die Formatbeschreibung der ASCII-Weiterverarbeitungsdatei ( Dok.-Nr.: 9226961) bekannt ist und dass die Datei die Voraussetzungen erfüllt, z.B. die Anzahl der Felder und andere Vorgaben (z.B. "wenn ein Kann-Feld nicht gefüllt ist, muss für dieses Feld trotzdem ein Semikolon eingefügt werden")
Gruß
Michael Vogtsburger
update:
ein Semikolon zuviel, zu wenig oder an der falschen Stelle kann den korrekten Import verhindern
Ich habe meine Weiterverarbeitungsdatei nach den Grundsätzen des Dok.-Nr.: 9226961 aufgebaut. Nun habe ich habe weiter mit NotePad++ experimentiert, verschiedene Zeichensätze ausgetestet, auf Leerzeilen geprüft, usw. Ich finde den Fehler nicht. Ich kann nicht erkennen, weshalb die ASCII-Weiterverarbeitung mit anderen Banken klappt und mit dieser nicht.
Nun läuft mir die Zeit davon und ich muss aufgeben. Vielleicht starte ich später einen weiteren Versuch.
Herr Vogtsburger, ich danke Ihnen trotzdem herzlich für Ihre Tipps und Anregungen!
Hallo Herr Bietz,
schade, dass Sie die Fehlerquelle noch nicht 'verhaften' konnten.
Es wäre schon interessant zu wissen, worin der Fehler liegt.
Vielleicht würde es helfen, hier die ersten paar Zeilen Ihrer ASCII-Datei anonymisiert zu posten. Es gibt hier in der Community sicher Einige (mich eingeschlossen), die an den Gründen für solche Fehlfunktionen und an deren "Reparatur" interessiert sind. Solche Dateien könnten einem ja selbst jederzeit mal begegnen.
Für mich selbst sind ASCII-Dateien immer nur 'primitive' Notlösungen, falls eine Fremdsoftware es nicht schafft oder es nicht schaffen will, die benötigten Daten in einem der gängigen Standard-Formate zur Verfügung zu stellen.
Das Datev-Format ist ja schließlich kein "Wald-und-Wiesen-Format" und eigentlich im Bereich Buchhaltungs-Software aus meiner Sicht ein Quasi-Standard, ein "Referenz-Format", an dem sich sehr viele Software-Hersteller orientieren (müssen).
... bin gespannt auf des "Pudels Kern"
Viele Grüße
Michael Vogtsburger
Hallo Herr Bietz,
schade, dass Sie die Fehlerquelle noch nicht 'verhaften' konnten.
Es wäre schon interessant zu wissen, worin der Fehler liegt.
Vielleicht würde es helfen, hier die ersten paar Zeilen Ihrer ASCII-Datei anonymisiert zu posten. Es gibt hier in der Community sicher Einige (mich eingeschlossen), die an den Gründen für solche Fehlfunktionen und an deren "Reparatur" interessiert sind. Solche Dateien könnten einem ja selbst jederzeit mal begegnen.
Für mich selbst sind ASCII-Dateien immer nur 'primitive' Notlösungen, falls eine Fremdsoftware es nicht schafft oder es nicht schaffen will, die benötigten Daten in einem der gängigen Standard-Formate zur Verfügung zu stellen.
Das Datev-Format ist ja schließlich kein "Wald-und-Wiesen-Format" und eigentlich im Bereich Buchhaltungs-Software aus meiner Sicht ein Quasi-Standard, ein "Referenz-Format", an dem sich sehr viele Software-Hersteller orientieren (müssen).
... bin gespannt auf des "Pudels Kern"
Viele Grüße
Michael Vogtsburger
Sie haben mich animiert, weiterzusuchen. Und dafür bin ich Ihnen dankbar!
Und ich habe nun die Bankkontoumsätze tatsächlich einspielen können. Ich habe etwas verrücktes ausprobiert. Ich habe die Datei in Word (!) geöffnet und von dort als Textdatei gespeichert (mit Endung .csv). Hier fragt das Programm nach Steuercodes. Auswahl: nur CR. Diese Datei lies sich tatsächlich einlesen.
Jetzt weiß ich zwar immer noch nicht, woran es in der Ursprungsdatei genau geklemmt hat und warum ich das in Notepad++ nicht erkennen konnte. Aber so habe ich wenigstens einen Workaround und kann bei Gelegenheit weiter suchen.
Für mich selbst sind ASCII-Dateien immer nur 'primitive' Notlösungen, falls eine Fremdsoftware es nicht schafft oder es nicht schaffen will, die benötigten Daten in einem der gängigen Standard-Formate zur Verfügung zu stellen.
Das kann man kaum treffender zusammenfassen.
... eigentlich besteht eine 'normale' Zeilenschaltung aus CarriageReturn(CR)+LineFeed(LF)
Wenn der 'Wagen-Rücklauf' (CarriageReturn) fehlt, ist die Zeile wie eine laaaaaaaaaaaaaange Wurst ohne Ende, aber schon im Lied "Alles hat ein Ende nur die Wurst hat zwei" erfährt man, dass eine Wurst (nicht einmal die Datev-ASCII-Wurst) nicht endlos sein kann
Glückwunsch zum erfolgreichen Import !
Michael Vogtsburger
Mal als Frage: warum lassen Sie sich die Datei nicht im MT940 - Format (also .sta) geben? Ich habe einen Mandanten, der ein Konto bei der DKB hat und der liefert jeden Monat in dem Format.
Wenn ich keine RZ-Bankinfo oder DUO-Kontoumsätze bekomme, frage ich auch immer nach MT940-Dateien. Der Mandant sagte, dass dieses Format nicht zur Verfügung stehen würde. Vielleicht kommt es darauf an, welches Kontomodell man bei der DKB hat?
Ich werde es jetzt aber auf jeden Fall noch mal hinterfragen. Danke für den Hinweis!
Ich frage mal meinen Mandanten. Nicht dass der eine Bankingsoftware nutzt, die das ermöglicht.
Aber auch das wäre interessant! Nämlich welche Software er in diesem Falle nutzt. Ich habe meinem Mandaten schon geraten, mit einer Testversion von Starmoney Deluxe zu experimentieren. Dann alles, was da rein läuft, kann im DATEV-Format exportiert werden.
Es wäre doch hilfreich, wenn man irgendwo in der Community einen Sammelthread hätte, indem man nachlesen könnte, bei welcher Bank welche Exportmöglichkeiten bestehen und welche Abhilfen sich bewährt haben, falls es nicht über RZ-Bankinfo oder MT940 geht.
Danke für Ihren Einsatz!
".STA" klingt z.B. nach der Software "SFirm".
Oft ist es nicht die Bank, die das MT940-Format zur Verfügung stellt, sondern die Banking-Software, die die z.B. per HBCI abgerufenen Kontoumsätze in diesem Format exportieren/speichern kann