Datenverlust bei Migration in Lexware Finanzmanager Version 2023

Stop - PixabayKurzer Hinweis für Blog-Leser, die den Finanzmanager von Lexware in der Version 2023 verwenden möchten. Das Programm wird ja gerne zur Verwaltung von Kontoständen bei Banken, sowie zur Unterstützung des Online-Banking eingesetzt. Die Software dürfte vor allem in kleinen Unternehmen im Einsatz sein. Mir liegt jetzt ein Leserhinweis vor, dass es bei der Migration auf diese Software in der Version 2023 zu einem Datenverlust kommen kann. Wäre nicht das erste Mal, dass Nutzer mit so etwas konfrontiert sind.


Anzeige

Eine Lesermeldung

Ein Blog-Leser hat sich vor einigen Tagen bei mir per Mail gemeldet, weil er bei Verwendung des Lexware Finanzmanager in der Version 2023 in ein unschönes Problem gelaufen ist und Daten verloren hat. Dazu schrieb er mir:

Lexware Finanzmanager in der aktuellen Version 2023 löscht ohne jegliche Nachfrage tlw. Jahrzehnte alte Daten bei der Migration.

Ich benutze den Finanzmanager und den Vorgänger Quicken seit weit über 20 Jahren. Immer schon habe ich Buchungen mit einem individuellen aussagekräftigen Verwendungszweck versehen, in dem ich eine, so wird es wohl genannt, Pseudosplit-Buchung verwendet habe.

Im Rahmen der Migration hat der Finanzmanager nun OHNE jegliche Rückfrage alle diese Verwendungszwecke auf den Verwendungszweck, der originär von der Bank kam, bei diesen Pseudosplit-Buchungen (also nur eine Transaktion, kein wirklicher Split) zurückgesetzt. Also statt "Mein Computer Buch" steht dort nun wieder bspw. "39X-82349552-12345678 AMZN Mktp DE 6************".

Ich habe das leider erst gestern gemerkt im Rahmen der Vorbereitung für meine Steuererklärung. Es war immer unglaublich praktisch sich einen Report zu erstellen, diesen als CSV zu exportieren und dann eine Auflistung der bspw. "Sonstigen Betriebsausgaben" per Copy und Paste in die Steuersoftware einzufügen. Geht nicht mehr wenn es nur eine Splitzeile war.

Auch während des Arbeitens mit dem Finanzmanager 2023 war es immer möglich eine solche "Pseudosplitbuchung" anzulegen, einen eigenen Text in den Verwendungszweck einzufügen der dann, tatataaa aber gar nicht übernommen wurde. Auch hier OHNE jeglichen Hinweis, ich habe das schlicht nie gemerkt. In meinem konkreten Fall habe ich

  • a) für 100 Tage Umsätze "meinen" Verwendungszweck ins "Leere" getippt, die sind weg. Und
  • b) durch das HBCI Abhollimit von 90 Tagen durfte ich beim Downgrade auf die Version 2022 zig Buchungen manuell eintippen.

Mir stehen jetzt noch zig Stunden Arbeit bevor. Ich bin fassungslos, wütend und verzweifelt über diesen Umgang mit Daten.

Wenig hilfreiche Workarounds

Der Leser schreibt, dass Lexware jetzt mit wenig hilfreichen Workarounds laboriere. In seiner Mail skizziert er die Versuche zur Problembehebung durch Updates der Lexware-Software:

  • In einem ersten Update wurde der Verwendungszweck (VWZ) der Bank mit dem selbst eingegebenen [Verwendungszweck] "kombiniert". [Das] setzte natürlich eine neue Migration der Daten voraus (bei mir halt 100 Tage alt) und auf Grund vorhandener Feldgrößenlimits wurde gerne auch hinten was „abgeschnitten".
  • In einem nächsten Update wurde es dann umgekehrt gemacht, erst der eigene Verwendungszweck, und dann der Verwendungszweck, der von der Bank gemeldet wurde. Hier wurde es nicht mal geschafft diese durch ein Leerzeichen zu trennen! Auch das setzte eine neue Migration der Daten voraus und bringt gar nichts für den oben aufgezeichneten Use Case solche in eine CSV exportierten Daten vernünftig weiter verwenden zu wollen.

Es ist furchtbar … wie kann man so verantwortungslos mit Daten umgehen. In einer Finanzsoftware. Einfach überschreiben, keinerlei Hinweis, keine Nachfrage, kein Konzept Daten zu erhalten einfach löschen.

Das Ganze ist natürlich ein Hammer – und wenn in einem kleinen Unternehmen viele Buchungen über diesen Finanzmanager abgewickelt werden, artet das in Stress und Arbeit aus.

Bestätigung im Forum

Ich habe mal auf die Schnelle geschaut, bereits mit dem Finanzmanager 2020 gab es laut diesem Forenbeitrag Datenverluste. Der Blog-Leser hat dann noch angemerkt, dass es im Lexware Forum folgenden Thread bezüglich der Problematik gibt. Dort wird das Problem auch mit Screenshots und Screencasts dokumentiert. Danke an den Leser für den Hinweis.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Software abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

17 Antworten zu Datenverlust bei Migration in Lexware Finanzmanager Version 2023

  1. Svenny sagt:

    Es wird kaum mehr Wert mehr auf klassische Entwicker gelegt, man stellt jetzt lieber billigere Framework Klicker und Product Owner und Online Marketing Manager ein. Das ist das Ergebnis. Selbst der Fix mangelhaft. Normal inzwischen. Leider.

  2. Alexander Jacubowsky sagt:

    Lexware ist leider dafür bekannt. Nicht nur beim Banking.
    Ich empfehle Alf Banco für das Banking.
    Tolle Software und Fehler werden teils noch am gleichen Tag behoben.

  3. Luzifer sagt:

    Sorry aber kein Backup kein Mitleid! (Gerade in Firmen erst recht).
    Das bei ner Migration immer mal was schief gehen kann ist ne Binsenweisheit. Selbst Microsoft empfiehlt bei nem Upgrade immer wieder nen Backup seiner Daten vorzuhalten und da geht es nur um das OS.

    Gerade wenn dann auch bekannt ist, daß Lexware nicht gerade die Nummer 1 bei sauberen Upgrades ist.

    Ist sicher ärgerlich, aber nix mit dem man nicht rechnen musste.

    • Olli sagt:

      Das Hochhaus ist halt eingestürzt – 500 Tote. Sind halt keine Ingenieure mehr nur noch Software-Klicker. So was weiß man doch, kann bei einer Sanierung immer mal passieren. Muss man immer mit rechnen. Warum wurde auch um die Baustelle mitten in der Innenstadt kein 1000 Meter Schutzradius gezogen?

      • Luzifer sagt:

        Insofern irrelevant, da Ingenieure Statiker usw. der Produkthaftung unterliegen und dafür ins Gefängnis gehen, während Softwareentwickler einfach nur mit den Schultern zucken. Produkthaftung bei Software gibt es einfach nicht!
        Und genau das ist das Problem!
        Softwareentwickler können pfuschen so viel und wann immer sie wollen, ohne wirklich ernsthafte Konsequenzen befürchten zu müssen.
        Da kommt dann, wenn man Glück hat, ein: oh tut uns leid, fixen wir im nächsten Patch.

        Außerdem, für deine Daten bist du verantwortlich!
        Ein weiteres Problem in der heutigen Zeit: niemand will mehr verantwortlich sein.

    • Lexware Kunde sagt:

      Augenscheinlich hast Du nicht richtig gelesen, bzw. sich mit dem Thema beschäftig sonst hättest Du Dir den Spruch "Kein Backup kein Mitleid" gespart.

      Es gab und gibt sehr wohl Backups!

      Wenn aber Daten OHNE Hinweis manipuliert werden und man das erst sehr viel später merkt, weil es zu einem solchen späteren Zeitpunkt erst relevant wird, dann verliert man beim notwendigen Downgrade und damit verbundenen älteren Datenstand aus dem BACKUP (!) schlicht Daten aus dem Zeitraum dazwischen. Da schützt kein verdammtes Backup vor.

      • Günter Born sagt:

        Ich habe schon den Eindruck, dass er in letzter Zeit bei den Kommentaren etwas zum "Überziehen" neigt – daher habe ich nicht geantwortet, da mir die gleichen Gedanken durch den Kopf gegangen sind.

        Der vom Bug Betroffene oder geneigte Leser weiß es imho aber einzuschätzen, dass es nicht am "fehlenden Backup" liegt, wenn Felder einfach nicht beim Import richtig zusammen gesetzt werden.

        Zudem hatte der Blog-Beitrag das Ziel, dass Betroffene bzw. Nutzer der Software ggf. vorab oder bei einer Suche über das Problem informiert werden und nicht lange bei sich selbst den Fehler suchen.

        • Chris sagt:

          Zumindest hat mich Dein Beitrag auf ein Problem aufmerksam gemacht.

          Die von Dir genannten Daten werden bei mir täglich gesichert. Auf eine SD Karte.
          Ich hatte aber eher einen Blitzschlag, eine abgerauchte Festplatte, versehentliche Löschung oder ein Updatefehler im Auge.

          Der von Dir genannte Fall würde mich also auch treffen.
          Daher rückt Versionierung bei mir ins Blickfeld.

          Ich habe zwar noch Datensicherungen in unregelmäßigen Abständen für die großen Datenmengen aber hier sprengt die Versionierung schnell die Festplattenkapazität und eine Datensicherung zum falschen Zeitpunkt würde mein unregelmäßiges Update auch wieder zerstören.

          Von daher von mir vielen Dank.

        • Luzifer sagt:

          Sorry aber ein Backup gehört auch überprüft … wer einfach nur ein Backup anfertigt ohne zu prüfen steht im Ernstfall ebenso mit runtergelassenen Hosen da.

          • Luzifer sagt:

            /edit/
            sind die Daten im Backup korrekt und nach dem Import nicht mehr, muss man eigentlich nicht mehr lange suchen.

            Zurück zur Vorgängerversion und Backup wieder einspielen, bis der Hersteller sich bequemt das zu fixen.

            Frag mal StarMoney, die hatten auch so Allüren zu glauben zu wissen was der Kunde braucht … nur hatten die nen Moneyback Versprechen, ging dann sehr schnell als die Kundschaft bei der neuen Version ihr Geld zurückhaben wollten und sie dadurch sehr schnell nen Fix nachschoben.

          • Lexware Kunde sagt:

            Du merkst nicht was für einen Quatsch Du schreibst, oder?

          • Chris sagt:

            @Luzifer : "Sorry aber ein Backup gehört auch überprüft …"

            Ich suche immer noch den Zusammenhang zu meinem Beirag. Den finde ich aber nicht. Um fehlerhafte Backups ging es nämlich nicht. Ich kann ein Backup noch so häufig überprüfen, ein fehlendes Backup ist dadurch nicht vorhanden.

            Auch die Überprüfung des Backups ist hier nicht wirklich zielführend.
            Meine Software ist eigentlich ein Synchronisierungs- bzw. Kopierprogramm.
            Wenn Du also hier noch einmal eine Überprüfung forderst, dann dürftest Du unter Windows keine Datei mehr verschieben. Denn das ist nichts Anderes als Kopieren und Löschen ohne Möglichkeit der Überprüfung.
            Anders sieht es bei der Einrichtung einer neuen Synchronsierung bzw. Backups. Da schaue ich zumindest, ob die Ordner- und Dateistruktur am Zielort vorhanden ist. Danach lasse ich die Backups laufen.

  4. Rudi sagt:

    N'Abend,
    lange rede kurzer Sinn:
    Nach dem Konvertieren einer alten Version auf 2023 sollte jeder SOFORT prüfen,
    ob für ihn ALLE bisherigen Arbeitsabläufe, Berichte, Auswertungen usw. wie gewohnt im Zugriff sind und auch funktionieren. Eine Kontrolle ist hier der springende Punkt.
    Beim Auftreten von Fehlern in der neuen Version (2023) sollte man mit dem altem Datenbankformat/FiMa-Version weiterarbeiten.
    N'8

  5. Lexware Kunde sagt:

    Ich liebe solche "Der Benutzer ist Schuld"-Aussagen ohne im Thema zu sein.

    * Keinerlei Hinweis oder Fehlermeldung bei der Migration
    * Einzeilige Splitbuchungen MIT USt. == KEIN Problem
    * Mehrzeilige Splits mit oder ohne USt. == KEIN Problem
    * Einzeiliger Split (sog. Pseudosplit, warum auch immer) ohne USt. == nach über 20 Jahren plötzlich ein Problem. Wird beim schließen des Dialogs einfach mit dem VWZ der Bank überschrieben.
    * Das Überschreiben fand ja nicht nur bei der Migration statt, sondern auch weiterhin beim gewohnten Arbeiten, NIEMALS kam ein Hinweis "Schön, dass Du jetzt was in das Feld geschrieben hast, ich übernehme das aber einfach mal nicht" – Ein Feld in das ich nichts eingeben darf, in das darf ich nichts eingeben!! Es hätte bspw. ausgegraut und geblockt sein müssen
    * Wäre DA spätestens ein Hinweis auf verändertes Verhalten gekommen, DANN wäre man wohl auch früher auf das Große Ganze gestoßen.

    Bitte erspart den Betroffenen solche Kommentare.

    • Bert Schulze sagt:

      Hi Lexwarekunde:

      Ich bin komplett bei Dir. Ich war auch sauer, als ich den Fehler bemerkte und daraufhin im Haufe-Forum den dortigen Thread dazu eröffnete und anschließend Sprüche kamen wie „kann keinen Fehler erkennen" oder „einzeilige Splitts sind keine Splitts" oder „wer braucht denn sowas". Und auch die Art, wie das heimlich umgesetzt wurde, sowohl bei der Datenmigration als auch in der weiteren Verwendung in Version 2023, wo die Eingabe zulässig war aber nach dem Speichern und Schließen der Buchung die Daten immer wieder neu gelöscht wurden. Sowas geht einfach nicht.

      Und noch schlimmer. Das hier war ja gar kein Fehler, sondern absichtlich so eingebaut, weil man einen Programmieraufwand vermeiden wollte, um Datenbankprobleme bei einzeiligen Splitts zu korrigieren, was ja nun, nach Wochen meines Bettelns im Forum, dann doch getan wurde.

      Zum Glück ist dieses Thema vom Tisch.

  6. netghost78 sagt:

    Inzwischen gibt es ein Update, der das Problem von Grund auf beheben soll:
    https://forum.lexware.de/threads/69231/post-392721

Schreibe einen Kommentar zu Svenny Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.