Seit Wochenanfang keine Umsatzabfrage mehr möglich

Da wäre das Flatpak dann eine Alternative. Aber das wird wahrscheinlich auch noch nicht die aktuelle Beta mitliefern.

Ja, aber vielleicht bewegen wir uns so langsam Richtung stable:

https://www.aquamaniac.de/rdm/news/39

Mit der aktuellen Beta ist endlich der Dialog implementiert. Vielen Dank an Martin

Du hast es nur mit diesen zwei Dateien und AqBanking 6.5.4 wieder zum Laufen bekommen? Funktioniert bei mit KMyMoney trotz CAMT Aktivierung und Abrufen Kontolisten/SEPA Information scheinbar nicht.

Wäre mit nämlich auch lieber als die Lösung mit der Beta Version, die läuft nämlich bei mir zur Zeit nur auf einem openSUSE Tumbleweed in einer VM, da ich so am unkompliziertesten an die neuen Versionen kommen kann.

@SirTux
hinzu kommt, dass bspw. bei jameica/hibiscus manche Pakete falsch/fehlerhaft von den Distr. erstellt wurden und somit zu Support-Problemen geführt haben.
Die Original-Version von der Entwickler-Page waren dann problemlos einsetzbar

PS: und gerade heute 16:36 Uhr wieder so ein Fall - forum/topic.php?p=182984#real182984

Ja.
Um möglichst wenig Spielraum für Missverständnisse zu lassen, hier nochmal meine Vorgehensweise etwas detaillierter:
Zunächst habe ich die beiden Dateien in den entsprechenden Verzeichnissen gespeichert.
Im zweiten Schritt habe ich dann für meine Konten die folgenden aqhbci-tool4 Kommandos ausgeführt



Nachdem der Umsatzabruf im Terminal erfolgreich war, habe ich GnuCash gestartet und dort das AqBanking Setup aufgerufen.
Dort habe ich mir dann nur die bereits vorhandene Kontenliste anzeigen lassen und dann wieder den "Schließen" Button geklickt und das Setup bis zum regulären Ende durch geklickt.
Danach war der Umsatzabruf wieder möglich.

Ob das Verfahren noch weiter vereinfacht werden kann vermag ich nicht zu sagen.
Man sollte es aber mMn im AqBanking Setup vermeiden den "Konto bearbeiten" Button zu klicken.
Wenn man das macht, ist nämlich die Camt Checkbox zunächst aktiviert (bedingt durch das "aqhbci-tool4 addaccountflags -a LocalUniqueId -f preferCamtDownload" Kommando) aber beim Schließen des Fenster geht diese Einstellung durch den Bug dann wieder verloren.

Bei mir hat das so mit GnuCash zum Erfolg geführt.
Könnte mir vorstellen, dass das bei KMyMoney analog funktionieren könnte.

Ich hatte das Problem auch und kann bestätigen, dass es mit obenstehender Anleitung wieder funktioniert.

Meine Umgebung:
Debian 13 Trixie, Gnucash 5.10 AQBanking 6.6.0.
Es mussten nur die zwei genannten Dateien ergänzt werden und die Konteninformationen wie beschrieben aktualisiert werden.

Ein Update auf die aqbanking beta war nicht notwendig.

Zunächst ganz allgemein zu AqBanking in den Linux Distros: Vielfach gibt es bereits Git Versionen, die in der Regel auf der übergreifenden Git des Projekts aufbauen. Das erleichtert das selber kompelieren und die automatische Versionspflege gaaanz erheblich. Zum Teil finden sich diese Git Versionen aber nur in bereits erweiterte Repositorien wie etwa AUR, die dazu freigeschaltet sein müssen. Unbedingt beachten: AqBanking braucht auch die aktuelle gwenhywfar Library, die ebenso als Git-Version installiert werden sollte! Das funktioniert nicht unbedingt automatisch als Abhängigkeit.

Den Entwicklern von Programmen wie AqBanking und Hibiscus hat man mit VoP und nun der Umstellung auf camt.052.001.08 einiges zugemutet. Was kommt als Nächstes?

Diese Entwickler waren aktuell auch sehr fleißig. Es gab viele neue Versionen und das Meiste läuft inzwischen. Ein großes Danke Sehr! an Martin und die weiteren Entwickler!

Zu: Rolling releases sind das andere Ende der selben "heißen" Stange namens "stabile Version", an der man sich die Griffel beizeiten verbrennt. - Wie SirTux schrieb:
Als Arch Linux damals auf das rolling release Verfahren umgestellt hat, habe ich zunächst aus genau diesem Grund auf Ubuntu umgestellt. Doch das rolling relesase hat sich weiter entwickelt. Vor allem Manjaro brachte ein abgestuftes Verfahren mit drei Branches, wie man sie dort nennt. Der Unstable Branch enhält sozusagen Nightly Builds für Entwickler, im Testing Branch können Beta Versionen reifen, und der Stable Branch ist durchaus für produktive Systeme geeignet, vor allem, wenn man die Verwendung von Community Programmen aus dem "Arch User Repository" AUR einschränkt. Neben Manjaro hat es weitere solche Entwicklungen gegeben.

Das Problem sind vor allem Beta Versionen und Fixes, auf die Einzelne oder gar eine breite Masse der Nutzer angewiesen sind. Naturgemäß gehören die eigentlich nicht auf produktive Systeme. Das sollte schon die Ausnahme sein. Da ist es gut, wenn man solche Ausnahmen wenigstens vernünftig handhaben kann, ohne das gesamte System zu einem Nightly Build zu machen. Es gilt: Gut mit Sicherheits-Updates versorgt zu sein, heißt nicht, ständig die neueste Alpha Version zu benutzen!

Flatpack oder Snap Pakete, die auch das ganze abhängige Drum Herum für den Disrtibutions-unabhängigen Einsatz mitbringen, könnten hier in der Tat von Vorteil sein. Das muss dann aber auch immer zusätzlich gebaut werden.

Doch auch Entwickler, die plötzlich in solch einer Feuerstelle sitzen, sollten sich nicht an das neue "Normal" gewöhnen. Auf heißen Kohlen ist es wohl für alle Beteiligten, auch für die Programmierer, extrem unangenehm. Manchmal zwingen ja Programmfehler, die Missbrauch ermöglichen, zu schnellem Handeln.

Was wir hier bei den Banking Programmen erleben, ist aber eine ganz andere Nummer. Nicht nur, aber gerade die Volks- und Raiffeisenbanken haben hier nicht zum ersten Mal innovative Standards auch für die Sicherheit gesetzt. Doch so löblich wie das ist, ist es eine große Lümmelei den Programmierern von Open Source Banking Lösungen das in überrumpelnder Weise vor die Füße zu schmeißen. Chaos, nix geht mehr, jetzt aber ganz zackig! - Das ist absehbar kein guter Stil! und der Sicherheit sehr abträglich. Und da ist es unsere Aufgabe als Bankkunde und Anwender Ross und Reiter zu benennen.

Die VR Banken leisten in der Öffentlichkeit vielfältige Unterstützung. Ein paar Euro Spende könnten hier in Ihrem ureigensten Interesse hilfreich sein. Als ggf. Genosse, Kunde und Anwender wir können nur inständig bitten, dass die Banken ihrer Profession nachgehen und den Programmieren mit Kommunikation und Kontaktpersonen, Dokumentation und insbesondere auch Test-Zugängen und Konten frühzeitig helfen, um solches Chaos gar nicht erst entstehen zu lassen.

Bei einer nativen Installation von aqbanking kann man ja wie beschrieben das Problem lösen durch Kopieren einer .xml und einer .conf -Datei nach $prefix/share/aqbanking/imexporters/...

Das geht so nicht, wenn aqbanking im gnucash flatpak integriert ist.

Aber, Lösung: aqbanking findet die beiden neuen Dateien auch, wenn sie im Home-Verzeichnis in .aqbanking/imexporters/xml/profiles/ bzw ../data/ platziert werden

Das ist auch bei einer nativen Installation vermutlich der geeignetere Ort, statt irgendwo in den Systemordnern.

Ein Problem kann noch folgendes sein (das mich länger aufgehalten hatte):

Wenn du die beiden camt_052_001_08.* Dateien über die zwei einzelnen Links hier im Thread herunterlädst, bei



und du machst das mit "rechte Maustaste" -> "Ziel speichern unter", dann stimmt der Datei-Inhalt nicht. Denn um sie wirklich herunterzuladen, müsste man sich bei aquamaniac.de anmelden. Mit obiger Methode hat man deshalb ohne es zu merken den html-Code des Anmeldedialogs in den beiden Dateien ...

Also weiter im Text des selben posts: