Hallo zusammen,

ich möchte von Moneyplex zu Hibiscus migrieren. Mir ist aufgefallen, dass Hibiscus beim Import via XML pro Buchung nur den Namen des Empfängers importiert. Die im XML ebenfalls vorhandene Kontonummer und BLZ des Gegenkontos wird offenbar ignoriert.

Das wurde auch schon mal gefragt, ging aber wohl unter.

Leider habe ich von Java keine Ahnung. An dieser Stelle sieht es so aus, als würde vom <EMPFAENGER> nur <NAME> behandelt.

Ich exportiere aus Moneyplex Version 25 Beta (Build L-24823) Umsätze im Format "XML-Export". Die stichprobenartig geprüften Daten haben folgendes Format (aus Datenschutzgründen habe ich Werte durch "-HIDE-" ersetzt):


Wäre es viel Aufwand, den Import wie folgt anzupassen?

• Wenn <ZUSATZ> vorhanden, dann dessen Inhalt hinten an NAME anhängen (Moneyplex splittet lange Empfängernamen auf zwei Felder auf und zeigt das selbst auch so an.)
  
• Wenn <BIC> vorhanden, dann als Gegenkonto BLZ setzen
  
• Wenn <IBAN> vorhanden, dann als Gegenkonto IBAN setzen
  

Laut Volltextsuche gibt es in der Datei UmsatzImpl.java analog zu setGegenkontoName() bereits Funktionen setGegenkontoNummer() und setGegenkontoBLZ(). Ich hoffe einfach mal, dass der Import mit wenig Aufwand ergänzt werden kann, und kann das dann auch gerne testen.

Vielleicht fehlt nur etwas in der Art?

die Vorab-Version für mehr Export-Möglichkeiten: https://matrica.de/wiki/index.php/Vorab-Version
danach CAMT-Export (siehe dein 1. Link)
bzw. forum/topic.php?t=27306

//edit: habe die Beta Version (warum auch immer im #1 überlesen

Hallo infoman,
leider hilft mir deine Antwort kein bisschen.

Oben steht ja, dass ich bereits mit der Vorabversion von Moneyplex arbeite. Der CAMT-Export enthält keine Kategorien und schneidet alle Verwendungszwecke bei ~140 Zeichen ab. Ich möchte aber den ganzen Verwendungszweck und meine jahrelang zugewiesenen Kategorien behalten, daher möchte ich den XML-Export nutzen.

Mit diesem Thread möchte ich herausfinden, ob der XML-Import die vorhandenen Daten aus einem bestimmten Grund ignoriert und ob sich das ggf. einfach beheben lässt. Abgesehen vom ignorierten Gegenkonto ist das XML-Format aus meiner Sicht nämlich spätestens seit der Änderung von rhierlmeier (Danke!) perfekt für alle Umsteiger, die Kategorien behalten wollen und Buchungen mit langem Verwendungszweck haben.

Und es könnte ja sein, dass der aktuelle Aufbau der Moneyplex-XML-Datei dem/den Hibiscus-Entwickler/n gar nicht bekannt ist, und das Gegenkonto nur deshalb fehlt.

Ja, wenn man die Kategorien behalten will, führt kein Weg an einem moneyplex XML-Export vorbei. CAMT ist ein - ich nenne es mal so - Bankformat und die Bank hat mit Kategorien nichts am Hut, vor allem nicht mit selbstdefinierten. Der Verwendungszweck ist in CAMT auf 140 Zeichen beschränkt. Ein Export von moneyplex muss abschneiden.

Ob ein Umweg über eine CSV-Datei hilft, weiss ich nicht. Es gibt ein perl-Skript, dass aus einer moneyplex XML-Datei eine CSV macht. Wenn man nun beim Import die richtigen Zuweisungen macht, könnte ich mir vorstellen, dass es klappt. (Habe ich genug Konjunktiv im Satz?)

Im banking4w Unterforum gibt es zahlreiche Infos und Tipps zum Export aus moneyplex.

PS: Ich hoffe, ich habe die Links richtig higekreigt, ansonsten muss man suchen.

Das war wohl in der Tat untergegangen oder ich hatte den Satz dort falsch verstanden. Mit deinem XML-Beispiel jetzt war es leicht zu verstehen und umzusetzen. Habe es ergänzt - https://github.com/willuhn/hib…1b22b571dc - ist morgen im Nightly-Build.

Das ging ja fix, vielen Dank!

Leider habe ich inzwischen noch eine Variante gefunden, siehe D) unten. Nicht erschrecken , das Nachfolgende dokumentiert vor allem die unterschiedlichen Varianten im XML-Export mit Beispielen - das meiste davon wird bereits korrekt importiert. Vielleicht kann damit jemand im Quellcode überprüfen, ob die Fälle A)-C) passend behandelt werden, und D) noch ergänzen.

---

Kleinster gemeinsamer Nenner - Folgende Tags sind bei mir in allen bisher gesichteten Buchungen enthalten:


Alles andere ist wohl optional und ggf. bei einzelnen Buchungen nicht vorhanden.
=> Nicht vorhandene Tags sollen keine Fehlermeldung produzieren, sondern als leere Daten importiert werden.

A) Es gibt Buchungen, bei denen <EMPFAENGER> existiert, aber komplett leer ist. Beispielsweise Geldabhebungen am Automaten und Abrechnungsbuchungen der Bank (dort fehlt dann sogar <BETRAG>).


B) Es gibt Buchungen, bei denen in <EMPFAENGER> nur <NAME> existiert. Betrifft bei mir Buchungen von 2014 und älter. (Diese werden bisher bereits korrekt importiert)


C) Feld <ZUSATZ>
Wo landet denn setGegenkontoName2() - Hibiscus zeigt doch nur ein Feld "Name" an?

Offenbar hat Moneyplex und/oder die Banken den Empfänger/Zusatz in der Vergangenheit unterschiedlich gehandhabt. Ich habe von ein und demselben Vertrag im Laufe der Zeit

• Buchungen, bei denen der überlange Empfänger in Moneyplex komplett im Feld Empfänger steht (~ seit 2019)
  
• Buchungen, bei denen der überlange Empfänger in Moneyplex einfach gekürzt ist (Zusatz ist in GUI leer, ~2017-2019)
  
• Buchungen, bei denen der hintere Teil des Empfängers in Moneyplex im Feld Zusatz steht (~ vor 2017)
  

In der Umsatzliste verkettet Moneyplex <NAME> und <ZUSATZ> mit einem einzelnen Leerzeichen.

Teilweise gehört dieses Leerzeichen dort nicht hin (ist dann mitten im Wort), teilweise aber schon. Sieht so aus, als hätte Moneyplex die beiden Teile vor dem Speichern getrimmt, und nicht bedacht dass es beim Verketten später einen Unterschied macht, ob die Teilung an einer Wortgrenze oder mitten im Wort erfolgte. Der Import kann das natürlich nicht reparieren, aber so importieren wie Moneyplex es zusammengesetzt anzeigte.

D) Tags <IBAN>, <BIC>, <KONTONR> und <BLZ>
Es gibt offenbar auch die Kombination <KONTONR> und <BLZ>.
Vorschlag:

Beispiele für beide Varianten, beides Lastschriften, am gleichen Tag auf dem selben Konto



E) Splittbuchungen
(werden bisher bereits korrekt importiert, nur der Vollständigkeit wegen aufgeführt)

Danke dass du dich von der Länge des Beitrages nicht hast abschrecken lassen

Das ist egal. Importiert wird nur, was vorhanden ist. Wenn XML-Elemente fehlen, wird das toleriert.

In der Umsatzliste erscheint es direkt mit in der Spalte "Name". In der Detailansicht wird ein separates Feld angezeigt, falls der zweite Name vorhanden ist.

Hab "KONTONR" und "BLZ" als Fallback noch hinzugefügt.

Ich habe das aktuelle 2.13.0-nightly (noch ohne Fallback) schon mal angetestet:
Bei den Buchungsdetails erscheint nun ein weiteres Feld "Name 2", falls es Daten enthält. Die zuvor leeren Felder für IBAN und BIC sind nun ebenfalls gefüllt. Buchungsdetails soweit so gut.

Bei den Umsätzen (also der Liste der Buchungen) steht in der Spalte "Gegenkonto" als Text aber "Name2+Space+Name". Sollte dort nicht "Name+Space+Name2" stehen?

Beispiel:
Name = "ARD ZDF DRadio Beitragsserv"
Name2 = "ice"
wird bei den Umsätzen falsch als Gegenkonto "ice - ARD ZDF DRadio Beitragsserv" angezeigt. Ist das ein ?

Das Verhalten bei der Anzeige ist Absicht. Grund: Bei SEPA enthält name2 den "Ultimate Debitor". Wenn ein Zahlungsdienstleister (z.Bsp. bei einer Kartenzahlung) involviert ist, dann steht im ersten Namen i.d.R. nur der Name des Zahlungsdienstleisters und erst in Name2 der eigentliche Empfänger.

Man könnte jetzt überlegen, die Felder nur im Moneyplex-Import zu vertauschen, damit es anschließend in der Anzeige wieder korrekt ist. Da müsste aber sichergestellt sein, dass die Reihenfolge in dem XML immer gleich ist.

Danke für die Erklärung.

Entscheiden darfst du das natürlich, aber ich würde das auf keinen Fall machen.

Die Vertauschung dürfte ja nur erfolgen, wenn <ZUSATZ> überhaupt existiert, und dann wäre ich irritiert wenn ich die vertauschten Buchungsdetails anschaue. Außerdem kann ich nur für meine Buchungen überprüfen was da vorkommt (Buchungen vor 2022 sehen auf manchen Konten diesbezüglich auch anders aus als aktuelle Buchungen, ein klares Schema kann ich bisher nicht erkennen). Es gibt aber natürlich noch viel mehr Banken mit denen ich nie zu tun hatte, die evtl. in der Vergangenheit kreativ waren und es gibt sicherlich noch ältere Moneyplexdaten als meine die ggf. damals auch anders gehandhabt wurden. Und wer weiß, welche Daten Banken künftig liefern und ob die "Umsätze"-Ansicht das in ferner Zukunft noch genau so anzeigen soll wie heute.

Für meine Daten und Konten würde ich Zusatz direkt mit in Name_1 importieren wollen, mit Leerzeichen verkettet. Ich kann aber verstehen, wenn du das so nicht im Quellcode und für alle Nutzer machen möchtest. Ist auch kein Problem, ich behebe das für mich einfach vor dem Import im XML. In erster Linie ging es mir ja um die Gegenkonto Nummer und BLZ, und die hast du ja schon eingebaut.

Falls das in Zukunft noch jemand so umwandeln möchte:

mit folgendem Python-Skript

Eine Sache habe ich bisher noch gefunden:



In diesem Fall wird es leider nicht toleriert, sondern führt auf einigen Konten (Sparkasse) zu einer Menge Fehlermeldungen beim Import. Ich vermute, die Fehlermeldungen sind alles Info-Buchungen der Bank ohne Betrag. Durch die Menge der Meldungen und der Kreativität der Sparkasse bei den Verwendungszwecken wäre es aber viel Aufwand, nachzuprüfen dass keine andere (=benötigte) Buchung aufgrund einer anderen Ursache fehlt.

Beispiel zum Nachvollziehen:

führt zu Meldung: "0 Umsätze erfolgreich importiert, 1 fehlerhafte übersprungen"

Lösungsvorschlag für Monexplex-Import: Falls <BETRAG> nicht existiert, dann Betrag auf 0 setzen.

Ja, das Setzen des Betrages auf 0 bei Fehlen wäre ein Workaround.

...den du vielleicht in den Import einbauen würdest?

Das "pattern" kommt mir bekannt vor:

aber, wie man sieht, mache ich es ohne Leerzeichen. Man hätte es bestimmt auch mit perl erschlagen können, aber so ein Einzeiler hat schon seinen Reiz.

Andererseits vermute ich, dass es nur wenige ehemalige moneyplex-Benutzer geben wird, die noch nicht auf eine andere SW umgestiegen sind und so etwas in Zukunft brauchen. Aber ich kann mich irren.

Da kannst du schon recht haben. Es gab aber auch Stimmen im Moneyplex Forum, die es weiterhin für Umsatzabrufe und Auswertungen nutzen wollen bis gar nichts mehr geht. Da wird es bestimmt auch in Zukunft noch den einen oder anderen Umsteiger geben.

Anyway, ich ergänze fehlende <BETRAG>0</BETRAG> nun vor dem Import im XML.

Ist denn absehbar, wann das nächste Release erscheint? Den ganzen Import mit einer morgen nicht mehr verfügbaren Nightly-Version zu machen fühlt sich irgendwie nicht gut an.

Nein, ist noch nicht absehbar. Aber was meinst du mir "morgen nicht mehr verfügbar"? Die Änderungen bleiben doch im Nightly-Build und werden nur um weitere neue Sachen ergänzt. Ab morgen ist auch das Tolerieren fehlender Beträge enthalten.

Dass der verfügbare Download, der morgen noch den gleichen Namen und die gleiche Versionsnummer (2.13.0-nightly) hat, sich anders verhält. Eben weil ggf. weitere Sachen ergänzt werden. Ich kann mir also nicht einfach aufschreiben "Import mit Version x.y durchgeführt", sondern nur "Import mit nightly Version mit letztem Commit xy durchgeführt". Und wo ich einer laufenden nightly-Version ansehe, welcher Commit drin ist, habe ich noch nicht herausgefunden.

Das ist natürlich kein Problem, aber falls in Kürze ein Release angestanden hätte, dann würde ich darauf warten.

Für den produktiven Betrieb würde ich in jedem Fall gerne das jeweils aktuelle Release verwenden. Kann ich Kontoanlage+Import mit der nightly-Version machen, dann zurück auf das aktuelle Release 2.12 gehen, und damit Umsätze abrufen und weiter arbeiten? Oder kann das zu Problemen führen?


Danke

Ja, du kannst wieder zurück wechseln. Es gibt derzeit keine Unterschiede in den Benutzerdaten bzw. der Datenbank.

Danke.