Ich versuche gerade Daten von Moneyplex nach Hibiskus zu migrieren.

Dabei erhalte ich am Ende die Meldung, dass von ~4000 Datensätzen rund 100 als ungültig übersprungen wurden.
Da in der Buchhaltung jeder übersprungene Datensatz inakzeptabel ist, wollte ich gern wissen welche Sätze das betrifft um selbst zu verstehen ob das Überspringen gerechtfertigt ist.

Gibt es ein Log des Import ggf auch welcher Datensatz den Fehler verursacht hat, damit ich dem nachgehen kann?

du hattest ja im Unterforum MP forum/topic.php?t=27575 gepostet
wie bist du vorgegangen, weil es wäre ja evtl. eher sinnvoll die Ursache am Ursprung zu suchen, als bei der Weiterverarbeitung

Ja.
Ich habe die 2025 Vorabversion installiert und dann den XML export gemacht.

Danach habe ich die Files in Hibiskus als "Matrica Format" importiert.

Ich sehe noch Probleme mit dem Encoding. Nach dem Import sind Umlaute "z.B. ü" kaputt.
Ist das ein Hibiskus problem? Oder auch Moneyplex?

Da ich die Logfiles nicht habe, weiß ich nicht was die Fehler sind. Ob es Umlaute sind oder komplett andere Dinge.

Das Moneyplex-Import-Format in Hibiscus ist sehr alt. Wahrscheinlich hat sich das Dateiformat inzwischen schon mehrmals geändert. Hibiscus erwartet, dass die Datei das Encoding "ISO-8859-1" besitzt. Ich nehme an, damals lagen die Dateien in diesem Encoding vor (ich denke, dass sie jetzt UTF-8 haben). Also öffne sie vor dem Import mal in einem Texteditor und speichere sie mit dem Encoding ISO-8859-1. Versuch dann den Import nochmal.

Ein dediziertes Import-Log gibt es nicht. Du kannst aber mal in der jameica.log schauen (siehe https://www.willuhn.de/wiki/doku.php?id=support:fehlermelden).

@KFlash
Nur zur Info: Die Software des Entwicklers Olaf Willuhn (alias hibiscus) schreibt sich mit c, das sollte doch höflichkeitshalber berücksichtigt werden.

Alles etwas schwierig, hier. Wenn man nicht weiss, was wie gemacht wurde, kann man nur raten.

Es geht um (moneyplex-)Buchungen, oder? Was ist hier XML? Moneyplex kann da schon verwirren. Im Kontext von Buchungen werden die Formate XML und CAMT angeboten. CAMT ist ein XML-Format. Was wurde denn benutzt, das moneyplex-XML oder das CAMT? Ich habe es nicht ausprobiert, aber ich vermute, dass das CAMT besser geeignet ist als das moneyplex-XML
Und wie schon von hibiscus gesagt, Hibiscus kann/kennt da nur ein altes moneyplex-Format

Hier im Forum gibt es Hinweise, dass ein Export im MT940-Format und ein Import im Swift MT940-Format wie gewünscht funktioniert hat - Umlaute ausgenommen, die man konvertieren muss/kann (auch dazu gibt es Hinweise). Dass die UTF-8-Codierung die Fehler verursacht, ist möglich. Die Wahrscheinlichkeit dafür kann ich nicht einschätzen.

IWenn auch mit CAMT und MT940 Fehler auftreten, muss man wohl die fehlerhaften Datensätze isolieren und mit den korrekt importierten vergleichen. Das kann aufwendig sein, je nachdem ob man abschnittweise exportiert oder Abschnitte per Programm/Editorin der Exportdatei öscht. (Das MT940 ist Text und man sieht schnell, was darin einen Datensatz ausmacht).

Verwirrend ist dann noch ...
Bei Überweisungen bietet moneyplex die Exportformate CSV und XML an. Hier ist XML das CAMT-Format.
Bei Buchungen gibt es noch das moneyplex interne MXL-Format, was vermutlich nur moneyplex versteht.

Hallo Herr Willuhn, danke für die Hinweise.
Da sich Moneyplex 2025 nun wirklich versucht aus dem Markt zu entfernen bin ich froh, dass es ihre Alternative gibt.

Die "Fehlerhaften Buchungen" sind besondere Buchungen ohne Betrag!

z.B.

oder

oder


Was wäre hier das empfohlene Vorgehen?
Betrag 0 ergänzen?

Edit: Regex zum suchen solcher Buchungen mittels kde kate:

Ja, eine andere Möglichkeit sehe ich hier nicht. Oder halt damit leben, dass diese Buchungen nicht mit übernommen werden.

Aha, es wurde also das moneyplex-XML-Format benutzt. Hat bei mir mit der dkb auch nicht funktioniert. Mit MT940 gings.

Aus meiner Sicht wäre die Benutzung von MT940 (und vermutlich auch CAMT) eine andere Möglichkeit.

Das Encoding hilft. Ich würde ihnen raten das Moneyplex-Format zu aktualisieren. Matrica vergrault gerade alle seine Nutzer. Nachdem ich seit 8Monaten(!) keine DKB Daten mehr abrufen konnte, sind jetzt auch noch die VR Banken ausgefallen. Die Leute brauchen eine andere Alternative und Hibiscus steht für Linux recht konkurrenzlos da.


Das hilft leider nicht. Die Import-Probleme werden komplett nicht dort geloggt. Wenn ich zumindest den "import Bericht" irgendwie rausziehen könnte.... aber der Verschwindet dann plötzlich nach paar Sekunden auf nimmer wiedersehen.

Ok, die restlichen Probleme fallen alle auf zu Lange Zweckfelder.

Aber da frage ich mich, wie macht hibiscus das wenn z.B. so eine Überweisung bei so ziemlich jedem Bürger aufschlagen müsste..:



Und die normalen Abrechnungsbuchungen sind im schnitt alle VIEL zu lang.
Wie geht Hibiscus mit denen um? Teilweise sind da ja auch Buchungsbeträge dran. Wenn man z.B. mal ne Unterdeckung für paar Tage hatte.

Ehrlicherweise werde ich jetzt nicht mehr anfangen, an dem Moneyplex-Dateiformat zu arbeiten. Es gibt ja noch ein Reihe weiterer gebräuchlicher Dateiformate, die i.d.R. sogar besser geeignet sind: CSV, Swift MT940, CAMT.

Klicke auf das Schloss-Symbol rechts in der Ecke des Logfensters. Dann bleibt es offen.

Ah, ok.
Die Schaue ich mir dann auch mal an. Bei CAMT weiß ich, dass die Kategorien alle weg sind. Deshalb war Moneyplex mein erster Versuch.

Ist die Längenbeschränkung von 255Zeichen für den Zweck Format bezogen, oder generell so?
Meine Banken haben im Zweck teilweise Epische Texte rein geschrieben (für Abrechnungen). Und teilweise, wenn z.B. eine Überzieheung im Monat vorlag, dann auch Beträge abgebucht. D.h. das sind alles keine "kannste wegwerfen" Buchungen, sondern echte Buchungen mit Inhalt.
Und natürlich auf der Rundfunkbeitrag der da auch drüber raus ging....

im CAMT Verwendungszweck ist das Feld auf 140 Zeichen beschränkt. Vermutlich hat man die alten 14x27 Zeichen für verschwenderisch gehalten - trotz XML Wasserkopf.

Was passiert dann beim Export? Einfach Truncate und gut?

So ist es. Einfach mal ausprobieren und schon sieht man es. Da sieht man auch, dass das MT-940- und das moneyplex-XML-Format nicht abschneiden. Dann kann man noch das CSV-Format probieren (wie man in moneyplex da aber die Spaltenüberschriften 'rein bekommt, weiss ich nicht; ggf. muss man beim Import die Spalten manuell zuordnen).

MT-940 und CAMT sind (genormte) Bank-Formate. Sie kennen keine Kategorien. Diese sind nur im moneyplex-XML und CSV 'drin (aber auch im Ausdruck, auf Papier, in der pdf- und/oder fp3-Datei).

Warum lange Verwendungszwecke beim Import der moneyplex-XML-Datei die weiter oben geschilderten Problem bereiten, weiss ich auch nicht.

D.h. Hibiscus kann längere Zwecke prinzipiell verarbeiten?

(Wenn dem so ist, dann ist die Längenprüfung eine Prüfung im Hibiscus-Moneyplex-importer.)


Dann könnte ich ja theoretisch einfach alles als Moneyplex (inkl Kategorien) importieren und dann nochmal einen CAMT export/Import nur für die zu langen buchungen machen...

Korrektur. CAMT ist auch längenbeschränkt. MT90 kann mehr. Ist aber vom Aufbau her deutlich undurchsichtiger.

Aktuell tendiere ich zu CSV (hat da jemand ein "Spaltenprofil" für den Moneyplex export?)

Alternative:
Moneyplex läuft ja weiterhin (ohne Onlinebanking), warum nicht als Archiv nehmen
... und nur die neueren Umsätze in der o.g. Software?

Wenn man die Hoffnung auf die Wiederbelebung von moneyplex noch nicht aufgegeben hat...
Man kann auch weiterhin moneyplex "benutzen". Ist "natürlich" aufwendiger, aber man verwaltet alle Daten mit einem Programm und macht nur die VoP-Überweisungen in der o.g. Software, oder im WebBanking - manuell oder per XML-Upload.