Siehe Abweichendes Benutzerverzeichnis nutzen.

Wenn du die Benutzerdaten auf einen anderen Computer oder ein anderes Betriebssystem umziehen möchtest, dann installiere Jameica auf dem neuen Computer oder Betriebssystem wie bei einer Neuinstallation. Kopiere anschließend das Benutzerverzeichnis auf den neuen Rechner bzw. in den neuen Homebereich des Benutzers. Alternativ kannst du auch das aktuelle, automatisch von Jameica erzeugte Backup importieren. Siehe Backups wiederherstellen.

Wenn du auf mehreren Computern oder Betriebssystemen mit Hibiscus auf deine Konten zugreifen möchtest, gibt es verschiedene Möglichkeiten, die jeweils mit unterschiedlichen Vor- und Nachteilen verbunden sind. Die folgenden Absätze erläutern diese.

Gemeinsam eingerichteter Bankzugang

Richte auf den Computern Hibiscus jeweils mit dem gleichen Bankzugang ein. Die gemeinsam nutzbaren Daten umfassen damit jedoch lediglich die abgerufenen Umsätze. Diese sind auch nach dem Abruf von der Bank weiterhin dort verfügbar (meist bis zu 90 Tage rückwirkend) und können damit von mehreren Computern aus abgerufen werden.

• Vorteile
  • einfach einzurichten
  • kein Server notwendig
• Nachteile
  • keine wirkliche gemeinsame Nutzung der Daten sondern lediglich mehrmaliger Abruf der Umsätze

Gemeinsam genutztes Benutzerverzeichnis

Starte Jameica mit einem abweichenden Benutzerverzeichnis. Wähle als Speicherort einen mobiles Laufwerk (z.Bsp. USB-Stick oder externe Festplatte). Dieses kannst du anschließend auf mehreren Computern benutzen.

• Vorteile
  • einfach einzurichten
  • kein Server notwendig
• Nachteile
  • Es können nicht mehrere Computer zeitgleich auf die Daten zugreifen
  • Höhere Gefahr von Datenverlust bei defekten USB-Sticks (das passiert gar nicht so selten) oder vorzeitigem Entfernen des Datenträgers, bevor alle Daten vollständig geschrieben wurden. Bei Verwendung eines Cloud-Laufwerkes kann es durch konkurrierende Schreibzugriffe zwischen Hibiscus und dem Cloud-Synchronisierungsdienst ebenfalls zu Datenverlusten kommen.

Hinweis: Verwende nach Möglichkeit nicht Dropbox oder stelle bei Verwendung eines Cloud-Laufwerkes zumindest nach Möglichkeit sicher, dass keine Dateisynchronisierung mit der Cloud stattfindet, während Hibiscus läuft. Es kann sonst zu konkurrierenden Schreibzugriffen und dabei zu Datenverlust kommen. Stelle bei der Verwendung eines Wechseldatenträgers (z.B. USB-Stick) sicher, dass dieser nicht vorzeitig entfernt wird alle noch offenen Schreibzugriffe durchgeführt wurden (In Windows mit der Funktion „Sicher entfernen“ bzw. „umount“ in Linux). Darüber hinaus kann es bei USB-Sticks häufig zu Lese- und Schreibfehlern kommen, wenn diese nicht mehr zuverlässig funktionieren.

Gemeinsam genutzte MySQL-Datenbank

In diesem Tutorial findest du eine Anleitung zur Einreichtung einer gemeinsam genutzten MySQL-Datenbank. Alle Umsätze, Konten und Zahlungsaufträge können dann von allen angeschlossenen Computern genutzt werden.

• Vorteile
  • gemeinsamer und gleichzeitiger Zugriff von mehreren Computern aus möglich
  • Benutzern kann reiner Zugang auf die Daten gewährt werden, ohne ihnen den eigentlichen Bankzugang zu geben
• Nachteile
  • Server oder zumindest ein im LAN gemeinsam nutzbarer Computer (das kann ggf. auch ein NAS sein) notwendig, auf dem die MySQL-Datenbank läuft
  • aufwändigere Einrichtung

Hibiscus speichert die Benutzerdaten standardmäßig im Verzeichnis „.jameica“ innerhalb des Homebereichs des Users. Siehe auch: Backups erstellen.

Jameica fragt jedoch beim Start, welcher Benutzerordner verwendet werden soll. Falls Jameica beim Start nicht mehr nach dem zu verwendenden Ordner fragt, dann klicke im auf „Datei→Einstellungen“ und aktiviere im Reiter „System“ die Option „Zu verwendenden Benutzer-Ordner bei Start auswählen“, um den Auswahldialog beim Start wieder zu aktivieren.

Wichtig

Aus Sicherheitsgründen darf sich das Benutzerverzeichnis nicht innerhalb des Programmverzeichnisses befinden. Auch wenn der Benutzer im Programmverzeichnis Schreibrechte besitzt, wird Jameica den Versuch, dieses (oder ein Unterverzeichnis davon) als Benutzerverzeichnis anzugeben, mit einer Fehlermeldung quittieren. Dieses Verfahren stellt sicher, dass Programmdaten nicht mit Benutzerdaten vermischt werden können.

Hinweis: Vermeide nach Möglichkeit keine Netzlaufwerke oder per Cloud synchronisierte Benutzerordner. Hierbei kann es zu unerwarteten Lese-/Schreibfehlern und Beschädigungen der Hibiscus-Datenbank kommen. Stelle bei synchronisierten Cloud-Laufwerken zumindest sicher, dass während der Ausführung des Programms die Synchronisierung pausiert, um Konflikte beim Dateizugriff zu vermeiden. Stelle bei der Verwendung eines Wechseldatenträgers (z.B. USB-Stick) sicher, dass dieser nicht vorzeitig entfernt wird (ohne die Funktion „Sicher entfernen“ bzw. „unmount“ zu verwenden). Darüber hinaus kann es bei USB-Sticks häufig zu Lese- und Schreibfehlern kommen, wenn diese nicht mehr zuverlässig funktionieren.

Durch den optionalen Startparameter „-f“ kann explizit ein abweichendes Verzeichnis (z.Bsp. auf einem USB-Stick) angegeben werden. Startet man Hibiscus also z.Bsp. wie folgt, dann wird als Benutzerverzeichnis das angegebene Verzeichnis gewählt:

Wenn das Benutzerverzeichnis Leerzeichen enthält, dann muss es mit Anführungszeichen umschlossen werden. Nicht:

jameica-win32.exe -f C:\Dokumente und Einstellungen\<abweichender username>\.jameica

…sondern:

jameica-win32.exe -f "C:\Dokumente und Einstellungen\<abweichender username>\.jameica"

Hibiscus und Jameica existieren jeweils in zwei Versionen. Zum einen die aktuelle und offizielle Release. Das sind jene Downloads, die auf den Projektseiten unter http://www.willuhn.de/products/hibiscus/download.php und http://www.willuhn.de/products/jameica/download.php angeboten werden. Zusätzlich existieren noch sogenannte „Nightly-Builds“. Sie werden jede Nacht automatisch aus dem aktuellsten Quellcode erzeugt und bilden die Grundlage für die kommenden Versionen. Sie sind zum Beispiel nützlich, wenn ein neues Feature oder ein Bugfix eingebaut wurde, welches nicht mehr in die aktuelle offizielle Release gelangte. Auf diese Weise können User „brandaktuelle“ Funktionen aus der künftigen Hibiscus-Version nutzen, noch bevor sie offiziell veröffentlicht wurden. Unter https://github.com/willuhn/hibiscus/blob/master/build/ChangeLog kannst du nachsehen, welcher Änderungen seit dem letzten Release bereits in das Nightly-Build eingeflossen sind.

Da Nightly-Builds jede Nacht automatisiert erzeugt werden, können diese Versionen ggf. (wenn auch selten) Fehler enthalten. Sie sind also vergleichbar mit sogenannten Beta-Versionen.

• Erstelle ein Backup des Benutzerverzeichnisses, um ggf. wieder auf die vorherige Version zurückwechseln zu können
• Lade die aktuellen Nightly-Builds von https://www.willuhn.de/products/hibiscus/download_ext.php und https://www.willuhn.de/products/jameica/download_ext.php herunter
• Führe das Update gemäß Anleitung durch

Hibiscus besitzt eine integrierte Limit-Prüfung, die verhindern soll, dass versehentlich ungewollt hohe Beträge überwiesen werden. Es ist standardmäßig auf 10.000,- EUR eingestellt. Der Wert kann vom Benutzer frei verändert werden. Öffne hierzu im Menu „Hibiscus>Einstellungen“ und trage den gewünschten Wert in der Option „Limit für Aufträge“ ein.

Wenn Hibiscus auf kleinen Displays (typischerweise von Netbooks) verwendet wird, kann es vorkommen, dass die Buttons am unteren Rand unter Umständen nicht sichtbar sind. Bei kleinen Bildschirm-Auflösungen (Höhe weniger als 700 Pixel - ab Jameica 2.8.7 bereits ab 800 Pixel) schaltet Jameica automatisch auf den Netbook-Modus.

Falls dennoch Scroll-Balken benötigt werden, obwohl der Bildschirm eine Höhe von mehr als 700 Pixeln (bzw. 800 Pixeln) besitzt, kann der Netbook-Modus erzwungen werden mit:

• Wechsle in das Jameica-Benutzerverzeichnis
• Wechsle in das Unterverzeichnis „cfg“.
• Erstelle dort eine Datei mit dem Namen: „de.willuhn.jameica.system.Customizing.properties“, falls sie noch nicht existiert.
• Öffne die Datei in einem Texteditor und füge folgende Zeilen hinzu (bzw. passe sie an, falls sie bereits vorhanden sind):

application.scrollview=true
application.scrollview.minheight=580
application.scrollview.force=true

Die Datei „de.willuhn.jameica.gui.util.Font.properties“ (befindet sich im Jameica-Benutzerverzeichnis) im Ordner „cfg“ steuert die Größe der Schriftarten.

Jameica verwendet - wenn es keine Datei gibt - beim nächsten Start die Systemschriftart und -größe.

Alternativ die Datei in einem Texteditor öffnen. Wenn sie nicht existiert, leg sie einfach neu an. Die folgenden (selbsterklärenden) Parameter beeinflussen die Schriftart und -größe der Standardschrift. Sie können beliebig geändert werden:

font.default.name=Tahoma
font.default.height=8
font.bold.name=Tahoma
font.bold.height=8

Jameica und Hibiscus unterstützen die Sprachen Deutsch und Englisch in der Benutzeroberfläche. Öffne die Datei „cfg/de.willuhn.jameica.system.Config.properties“ (befindet sich im Jameica-Benutzerverzeichnis) in einem Texteditor.

Lege folgende Zeile neu an oder ändere die bereits vorhandene:

jameica.system.locale=de_DE

Das ist die Einstellung für Deutsch. Für englische Sprache, ändere das „de_DE“ in „en“.

Ab Jameica 2.8.7 ist die Sprache bequem via „Datei→Einstellungen“ konfigurierbar.

Dialoge, die mit „Ja“ oder „Nein“ beantwortet werden können, enthalten meist eine Option „Diese Frage künftig nicht mehr anzeigen“, um die Antwort dieser Frage permanent zu speichern. Es gibt direkt im Programm leider keine Benutzeroberfläche, um die gespeicherten Antworten zurückzusetzen. Die Antworten werden aber in einer Konfigurationsdatei gespeichert, die bearbeitet (um einzelne Antworten zurückzusetzen) oder alternativ einfach gelöscht werden kann (um alle gespeicherten Antworten zurückzusetzen).

Öffne hierzu die Datei „cfg/de.willuhn.jameica.system.ApplicationCallback.properties“ (befindet sich im Jameica-Benutzerverzeichnis) in einem Texteditor.

Entferne die Zeilen mit den zu löschenden Antworten oder lösche alternativ die gesamte Datei.

Bei einigen Banken werden die Felder Konto-Inhaber, Kontonummer und BLZ im Gegenkonto der Umsatzbuchung nicht korrekt gefüllt. Stattdessen erscheinen die Informationen „lose“ im Verwendungszweck. Ursache hierfür ist das Übertragungsformat der Bank. Im HBCI-Standard (konkret Swift MT940) sind zwei Verfahren für die Übertragung dieser Informationen zulässig. Strukturiert und Unstrukturiert. Im Fall 1 sendet die Bank alle Felder sauber getrennt, sodass sie von einem Banking-Programm (wie Hibiscus) problemlos in die zugehörigen Felder der Anwendung übernommen werden können. Im Fall 2 (unstrukturiert) sendet die Bank Kontonummer, BLZ, Inhaber und Verwendungszweck in einem Feld - ohne irgendwelche Trennzeichen, sodass das Banking-Programm die einzelnen Felder nicht zuordnen kann. Für einige wenige Banken wurde in Hibiscus zwar ein Parser implementiert, der die Gegenkonto-Informationen aus dem Verwendungszweck fischt (siehe auch Blog). In den meisten Fällen wirst du aber mit diesem Umstand leben müssen. Wenn die Bank nicht in der Lage ist, die Gegenkonto-Informationen in einem lesbaren Format zu übertragen, kann Hibiscus auch nichts machen. Wende dich bitte an deine Bank.

Wenn du EXAKT beschreiben kannst, wie der Verwendungszweck bei deiner Bank aufgebaut ist - also in welcher Zeile sich in welchem Format die Gegenkonto-Informationen befinden, dann kannst du das in Bug 887 melden. Eventuell kann dann auch für deine Bank ein Rewriter programmiert werden, der die Gegenkonto-Informationen extrahieren kann.

Das sind sogenannte „Vormerkbuchungen“. Hierbei handelt es sich um Umsätze, die von der Bank noch nicht valutiert wurden, aber schonmal als „Vorabinfo“ bereitgestellt werden. Da sie noch nicht valutiert sind, ist der Saldo (Zwischensumme) noch nicht bekannt. Sobald die Buchungen von der Bank valutiert wurden (in der Regel am Folgetag), werden sie in Hibiscus automatisch gegen die „echten“ Buchungen ersetzt. Vormerkbuchungen sind also nichts anderes als ein Hinweis auf kommende Buchungen.

Mögliche Ursachen:

• Hibiscus holt immer nur genau die Umsätze ab, die seit dem letzten Abruf neu hinzugekommen sind. Konnten nun beim letzten Mal nicht alle Umsätze abgerufen werden, dann bleiben die im aktuellen Abruf ggf. unberücksichtigt. Abhilfe: Rückwirkend abrufen
• Der Abruf der Kontoauszüge ist in den Synchronisierungseinstellungen des Kontos überhaupt nicht aktiviert. Abhilfe: Öffne hierzu das betreffende Konto durch Doppelklick. In den Konto-Details findest du einen Button „Synchronisierungsoptionen“. Nach einem Klick darauf öffnet sich ein Dialog, in dem eingestellt werden kann, welche Aktionen Hibiscus beim Synchronisieren für dieses Konto durchführen soll. Ggf. ist dort die Option „Umsätze abrufen“ nicht aktiviert.
• Die Bank hat derzeit ein technisches Problem, das sich von allein lösen sollte.
• Der Geschäftsvorfall „Umsatzabruf“ wird für dieses Konto nicht unterstützt. Wende dich hierzu bitte an deine Bank.
• Auf dem Konto sind überhaupt keine neuen Umsätze eingetroffen. ;)

Es sind Fälle bekannt, in denen eine Bank Umsätze rückwirkend nachgemeldet hat, obwohl sie bereits aktuellere Umsätze lieferte. Wenn das einmalig auftritt, hilft rückwirkend abrufen. Falls es regelmäßig auftritt:

• Wechsle in das Jameica-Benutzerverzeichnis
• Wechsle in das Unterverzeichnis „cfg“.
• Öffne die Datei „de.willuhn.jameica.hbci.HBCI.properties“ in einem Texteditor und füge dort folgende Zeile hinzu (oder ändere sie, falls sie schon vorhanden ist):

umsatz.startdate.offset=-2

Der Wert „-2“ bewirkt, dass neue Umsätze nicht nur ab dem Datum des letzten Abrufs geholt werden sondern zusätzlich auch immer nochmal die von den beiden Vortagen. Bei diesem Verfahren kann es jedoch unter Umständen zu doppelten Umsätzen kommen, falls die Bank Umsätze rückwirkend nicht nur hinzufügt sondern auch ändert. Diese Doppler können problemlos gelöscht werden.

Generell sollte dieser Konfigurationsparameter nur dann verwendet werden, wenn die Bank tatsächlich rückwirkend Umsätze liefert - was sehr selten, jedoch leider schon vorgekommen ist.

Wichtig: Die Funktion ist nicht dafür gedacht, Umsätze eines größeren Zeitraumes rückwirkend erneut abzurufen, sondern nur dafür, wenn die Bank teilweise noch Buchungen vom Vortag nachreicht. Ein kleinerer Wert als „-2“ macht daher in aller Regel keinen Sinn. Für das einmalige rückwirkende Abrufen von Umsätzen siehe folgender Absatz.

Falls man Umsätze aus den Kontoauszügen gelöscht hat, es bei einem vorherigen Abruf zu einem Fehler kam oder aus anderen Gründen zwischendrin welche fehlen, kann man diese oft nachträglich nochmal von der Bank abrufen. Die Banken bieten in der Regel die Umsätze der letzten 90 Tage über ihre FinTS-Server an. Hibiscus ruft jedoch normalerweise nur die neuen Umsätze ab, die seit dem Datum des letzten Abrufs (der auch fehlgeschlagen sein kann) hinzugekommen sind. Öffne die Liste der Konten in Hibiscus. Klicke mit der rechten Maustaste auf das betreffende Konto und wähle im Kontextmenü die Option „Erweitert→Saldo und Datum zurücksetzen…“. Dadurch wird das Datum des letzten Abrufes in Hibiscus gelöscht. Beim nächsten Abruf von Kontoauszügen werden nun nicht mehr nur die neuen Umsätze abgeholt sondern alle bei der Bank verfügbaren. Das sind meist die letzten 90 Tage. Falls anschließend einige Umsätze doppelt erscheinen, können sie problemlos gelöscht werden.

Wenn Umsätze falsch übertragen, gelöscht oder nachträglich importiert wurden, kann es vorkommen, dass die Zwischensumme einiger Umsätze nicht mehr korrekt ist. In dem Fall kann eine Neuberechnung der Zwischensummen durchgeführt werden.

• Suche hierfür die letzte Umsatzbuchung, deren Zwischensumme noch korrekt ist.
• Markiere diesen Umsatz als geprüft (Rechtsklick auf den Umsatz und im Kontextmenü „Als geprüft markieren“ wählen).
• Stelle sicher, dass alle nachfolgenden Umsätze des betreffenden Kontos nicht als geprüft markiert sind (entferne die Geprüft-Markierung dieser Umsätze ggf. wieder).
• Öffne dann die Liste der Konten (links in der Navigation auf „Konten“ klicken) und wähle das betrffende Konto
• Klicke mit der rechten Maustaste auf das Konto und wähle im Kontextmenü „Erweitert→Salden neu berechnen…“

Hibiscus berechnet daraufhin die Zwischensummen aller Umsätze nach dem letzten geprüften Umsatz neu.

Die in der Spalte „#“ angezeigte Nummer in der Umsatzliste ist keine fortlaufende Nummerierung von Umsätzen des Kontos sondern der interne Datenbank-Schlüssel des zugehörigen Datensatzes in der Hibiscus-Datenbank (sog. Primary Key). Dieser Schlüssel wird auch nicht von der Bank übertragen sondern von Hibiscus-Datenbank intern generiert. Ausserdem wird er nicht pro Konto gezählt sondern pro Hibiscus-Installation. Wenn also mehrere Konten in Hibiscus eingerichtet sind, verteilen sich die Nummern auch auf alle Konten - und zwar in der Reihenfolge, in der die Umsätze von der Bank abgerufen oder vom Benutzer importiert wurden. Ebenso treten beim manuellen Löschen von Umsätzen durch den Benutzer bzw. beim automatischen Löschen von Vormerkbuchungen (wenn die zugehörigen valutierten Buchungen eingetroffen sind) Lücken in der Nummerierung auf, die auch nicht neu gefüllt werden.

Die Werte der Spalte „#“ beginnen also nicht (ausser eventuell beim ersten eingerichteten Konto) mit 1 und die Nummerierung erfolgt auch nicht lückenlos. Wenn also Lücken auftreten oder die Nummerierung in dem Konto nicht mit 1 beginnt, ist das *kein* Indiz, dass vermeintlich Umsätze fehlen. Und da diese Nummern nur von Hibiscus intern generiert werden, kennt auch deine Bank sie nicht.

Die Spalte „#“ dient lediglich dazu, die Umsätze genau in der Reihenfolge (konten-übergreifend) sortieren zu können, in der sie abgerufen/importiert wurden - unabhängig davon, welches Valuta- oder Buchungsdatum sie tragen.

Hibiscus unterstützt auch manuell geführte Konten (in manchen Anwendungen „Barkonten“ genannt). Erstelle hierzu manuell ein neues Konto (Klicke links in der Navigation auf „Konten“ und anschließend auf „Neues Konto“. Aktiviere dort die Option „Offline-Konto“. Anschließend können Umsatzbuchungen in diesem Konto manuell angelegt und bearbeitet werden.

Hibiscus unterstützt auch das Ausführen wiederkehrender Aufgaben (wie das Abrufen der Umsätze aller Konten oder die Ausführung fälliger Überweisungen) in einem Rutsch. Die Funktion heisst in Hibiscus „Konten synchronisieren“. Im Handbuch findet sich die Beschreibung hierzu.

Hibiscus prüft Kontonummern anhand der letzten Ziffer (Prüfziffer). Wenn die Fehlermeldung „Ungültige BLZ/Kontonummer. Bitte prüfen Sie Ihre Eingaben“ erscheint, ist die Kontonummer oder BLZ in aller Regel tatsächlich falsch. Prüfe daher die Bankverbindung auf eventuelle Tipp-Fehler odere Zahlendreher. Wenn du dir ganz sicher bist, dass die Bankverbindung korrekt ist, kannst du die Prüfung zeitweise wie folgt deaktivieren: Wähle oben im Menu „Hibiscus→Einstellungen“. Deaktiviere dort die Option „Kontonummern und Bankleitzahlen mittels Prüfsumme testen“.

Beim Versuch, ein Kreditkarten-Konto mit einer meist 16-stelligen Kontonummer anzulegen, erscheint die Meldung „Der Text “…„ ist zu lang. Bitte geben Sie maximal 10 Zeichen ein“. Ebenso wird das Konto bei der automatischen Anlage von Konten (beim Einrichten eines neuen Bankzugangs) übersprungen.

Hibiscus unterstützt nur die für Giro-Konten typischen HBCI-Geschäftsvorfälle. Die Limitierung auf maximal 10 Stellen bei der Kontonummer ist also keine versehentliche oder willkürliche Grenze sondern soll verhindern, dass in Hibiscus Konten angelegt werden, die von Hibiscus gar nicht unterstützt werden. Das Problem ist also nicht das zur kurze Eingabefeld sondern die Tatsache, dass Hibiscus keine Unterstützung für die HBCI-Geschäftsvorfälle von Kreditkarten-Konten enthält. Würde sich das einfach durch bloßes Verlängern des Kontonummer-Eingabefeldes lösen lassen, hätte ich das doch schon längst getan ;)

Die Programmierung der hierfür nötigen Geschäftsvorfälle in HBCI4Java/Hibiscus ist mit einigem Aufwand verbunden, für den bisher noch keine Zeit war.

Die BPD (Bank-Parameter-Daten) werden beim Einrichten eines neuen Bankzugangs von der Bank an Hibiscus übertragen. Sie enthalten alle für das Bankingprogramm nötigen Informationen zur Ausführung von Geschäftsvorfällen. Dort steht z.Bsp. drin, ob die Bank Termin-Überweisungen unterstützt, welche TAN-Verfahren sie anbietet, in welchem Format Umsatzbuchungen abgerufen werden können und vieles mehr. Darüber hinaus gibt es die UPD (User-Parameter-Daten). Diese enthalten Informationen, die sich direkt auf die eigene Benutzerkennung beziehen - z.Bsp. die mit dem Bankzugang verknüpften Konten, die TAN-Medienbezeichnungen, usw.

Sowohl die BPD als auch die UPD besitzen jeweils eine Versionsnummer. Bei der Kommunikation mit der Bank sendet Hibiscus die vorliegende Versionsnummer an die Bank. Stellt diese fest, dass die Daten veraltet sind, sendet sie aktualisierte BPD/UPD, die von Hibiscus automatisch übernommen werden.

Unter Umständen kann es jedoch vorkommen, dass diese Aktualisierung nicht oder nicht rechtzeitig stattfindet (manche Banken erhöhen die Versionsnummern nicht korrekt). Die BPD können daher auch manuell erneut abgerufen werden. Öffne hierzu die Detail-Ansicht des Bank-Zugangs unter „Bank-Zugänge→Doppelklick auf den jeweiligen Bank-Zugang“. Klicke dort auf den Button „BPD/UPD“ und anschließend auf „BPD löschen“. Schließe das Fenster und klicke dann auf „Konfiguration testen“. Hierbei werden die BPD neu von der Bank abgerufen. Klicke bei der anschließenden Frage, ob die Konten neu angelegt werden sollen, auf „Nein“. Wenn das nicht hilft, kann es nötig sein, den Bankzugang zu löschen und anschließend neu anzulegen. Die Konten und Umsätze gehen hierbei nicht verloren.

Die häufigsten Fehlerursachen:

• Du hast in Hibiscus die Adresse des regulären Internet-Banking-Angebots (via Webbrowser) der Bank angegeben, in der PIN/TAN-Konfiguration von Hibiscus also einfach die URL verwendet, die du auch sonst im Browser benutzt. Der Zugang über den Browser (Webbanking-PIN/TAN) und über Hibiscus (FinTS-PIN/TAN) sind jedoch zwei völlig verschiedene Zugangswege zur Bank, die nur eines gemeinsam haben: Die Eingabe von PIN und TANs. Wenn du also bisher die Bankgeschäfte online im Webbrowser gemacht haben, dann versuche nicht, diese HTTPS-URL auch für Hibiscus verwenden zu wollen - es wird mit Sicherheit fehlschlagen. Stattdessen: Lege einen neuen PIN/TAN-Bankzugang in Hibiscus an. Nach der Eingabe der BLZ trägt Hibiscus automatisch die korrekte Server-Adresse in das Eingabefeld ein. In aller Regel ist diese Adresse korrekt und muss nicht geändert werden
• Stelle sicher, dass bei der Bank tatsächlich HBCI-PIN/TAN freigeschaltet ist. Falls dir die Eingabe-Felder für Benutzerkennung und Kundenkennung beim Anlegen eines neuen Bankzugangs in Hibiscus spanisch vorkommen, ist dies ein deutliches Zeichen für einen fehlenden Zugang. ;)
• Du benutzt die falsche HBCI-Version. In aller Regel wird „FinTS 3.0“ verwendet.

Wenn diese Fehlermeldung beim Verbindungsaufbau auftritt, ist deine Java-Version zu alt. Stelle sicher, dass mindestens Java 8 installiert ist. In der Log-Datei jameica.log findet sich hierbei folgende Fehlermeldung:

javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

Die HBCI-Version 2.2 und HBCI+ akzeptieren nur maximal 6-stellige PINs. Falls die PIN also mehr als 6 Ziffern besitzt, funktioniert dies nur bei Verwendung der HBCI-Version „FinTS 3.0“.

Dies kann mehrere Ursachen haben.

Die TAN-Generatoren einiger Hersteller funktionieren nicht mit allen Monitoren auf Anhieb. Bei den Geräten von Kobil müssen in den Einstellungen des TAN-Generators ggf. einige Werte geändert werden. Lies hierzu https://www.kobil.com/nc/de/flickersupport/faq.html Für andere Hersteller wird es ggf. auch solche Einstell-Möglichkeiten geben. Wende dich hierzu an den Hersteller deines TAN-Generators bzw. suche auf dessen Webseite nach einer Problemlösung.

Verwende in dem Hibiscus-Fenster mit der Flicker-Grafik das Eingabefeld „Geschwindigkeit“, um die Blink-Geschwindigkeit zu senken. Hibiscus unterstützt zwar Blink-Geschwindigkeiten bis zu 40 Hz, TAN-Generatoren müssen laut Spezifikation jedoch nur bis zu 20 Hz unterstützen. Wähle daher anfangs immer einen Wert von unter 20.

In dem Hibiscus-Fenster mit der Flicker-Grafik befinden sich zwei Buttons „-“ und „+“, mit denen die Größe der Grafik angepasst werden kann. Stelle sie so ein, dass die beiden abgebildeten Dreiecke (über dem ersten und fünften Balken der Grafik) in der Breite exakt mit den Dreiecken am TAN-Generator übereinstimmen.

Die optischen Sensoren der TAN-Generatoren sitzen zwar in einem Rahmen, der Umgebungslicht abschirmt, ungünstige Lichtverhältnisse (stark seitliches Sonnenlicht, Schreibtischlampe über dem Monitor o.ä.) können die Datenübertragung trotzdem beeinträchtigen. In einem solchen Fall ist es notwendig, den störenden Lichteinfall zu beseitigen. Außerdem hilft es, den TAN-Generator in einem solchen Winkel zu halten, dass die Auflagefläche um die Sensoren möglichst plan am Monitor anliegt.

Flicker-Codes existieren in mehreren Standards. Aktuell ist der Standard „HHD 1.4“, welcher ca. im Dezember 2010 veröffentlicht wurde. Unter Umständen kann es sein, dass deine Bank zwar bereits HHD 1.4 verwendet, dein TAN-Generator jedoch zu alt ist und diese neuen Flicker-Codes noch nicht lesen kann. Um das zu überprüfen, sind zwei Fragen zu klären:

1. Ist dein TAN-Generator HHD-1.4 tauglich? Stecke hierzu deine Karte in den TAN-Generator, drücke die Taste „TAN“ und gib den Startcode „12345“ ein, bestätige mit „OK“. Wenn im Display „Terminüberw. SEPA“ angezeigt wird, ist das Gerät HHD-1.4-tauglich. Wird jedoch „Daten:“ angezeigt, ist es ein älteres Gerät, welches noch kein HHD 1.4 beherrscht. (siehe auch)
2. Finde heraus, ob deine Bank tatsächlich bereits HHD 1.4 verwendet. Wenn sie das nicht tut, brauchst du auch keinen HHD-1.4-tauglichen TAN-Generator und dein bisheriger sollte funktionieren. Frage hierzu am besten bei deiner Bank nach.

Falls deine Bank tatsächlich bereits HHD 1.4 verwendet UND dein TAN-Generator noch NICHT HHD-1.4-tauglich ist (und du keine Lust hast, einen neuen TAN-Generator zu kaufen), kannst du Hibiscus so konfigurieren, dass es versucht, HHD 1.4 zu vermeiden. Nochmal: Tu dies NUR, wenn die beiden genannten Bedingungen bei dir zutreffen. Öffne das Hibiscus-Benutzer-Verzeichnis und erstelle eine neue Textdatei mit dem Namen „hbci4java.properties“:

Füge folgende Zeile in dieser Datei ein:

kernel.gv.HITANS.segversion.max=4

Starte Hibiscus neu, öffne die Details der PIN/TAN-Konfiguration, klicke dort auf den Button „BPD/UPD“. Klicke in dem sich öffnenden Fenster auf den Button „BPD löschen“. HHD 1.4 wird erst seit HITANS in Segment-Version 5 verwendet. Durch den Eintrag in dieser Datei wird HITANS höchstens in Segment-Version 4 verwendet, was wiederrum bedeutet, dass höchstens HHD 1.3 (ja ich weiss, ist irritierend ;)) zur Anwendung kommt. Mit etwas Glück bietet deine Bank das optische chipTAN-Verfahren nicht nur in HHD 1.4 an sondern auch noch in HHD 1.3.

Falls der TAN-Dialog schonmal funktionierte und erst seit Hibiscus 2.10.3 der Fehler besteht, dann lösche bitte die Datei „de.willuhn.jameica.hbci.passports.pintan.PhotoTANDialog.properties“. Du findest sie im Jameica-Benutzerordner im Unterverzeichnis „cfg“:

Server-Adresse und Benutzerkennung sind auf der Chipkarte gespeichert. Um diese Daten zu ändern, existieren mehrere alternative Möglichkeiten:

Öffne die Kartenleser-Konfiguration über „Bank-Zugänge→Chipkarte→Doppelklick auf die Kartenleser-Konfiguration“. Erhöhe dort den Wert des Parameters „Index des HBCI-Zugangs“ um 1. Meist steht der auf „1“. Setze ihn auf „2“. Klicke nun auf „Speichern“ und anschließend auf „Einstellungen testen“. Jetzt sollte ein Dialogfenster erscheinen, indem du die neue Server-Adresse und Benutzerkennung eintragen kannst. Falls das Fenster nicht erscheint, dann erhöhe den Index ein weiteres mal - also auf 3. Falls das Fenster immer noch nicht erscheint, dann auf 4. Sollte bei keinem der Werte das Fenster erscheinen, ist deine Chipkarte bereits an allen 4 Speicher-Plätzen mit einem Zugang versehen.

Öffne die Kartenleser-Konfiguration über „Bank-Zugänge→Chipkarte→Doppelklick auf die Kartenleser-Konfiguration“. Klicke auf den Button „Bankdaten ändern“.

Falls keine der beiden erstgenannten Möglichkeiten funktioniert, bleibt nur noch der Umweg über ein anderes Programm. Lade dir hierzu beispielsweise eine Demo-Version von Starmoney aus dem Internet oder die DDBAC-Runtime und installiere diese. Beide Programme unterstützen das Ändern der Chipkarten-Daten. Anschließend kann die Karte auch in Hibiscus wieder problemlos verwendet werden.

Das Problem kann bei der Verwendung von ReinerSCT-Kartenlesern mittels PC/SC auf neueren Linux-Distributionen auftreten, welche „systemd“ verwenden. Ursache scheint die dort verwendete Option „auto-exit“ des PCSCD zu sein, welche bewirkt, dass sich der Daemon irgendwann beendet, anschließend jedoch scheinbar nicht mehr richtig re-initialisiert wird. Im Forum unter https://homebanking-hilfe.de/forum/topic.php?p=113568#real113568 ist das näher beschrieben.

Bei der Verwendung mehrerer Chipkarten kann es zu Problemen kommen, wenn bei der Konten-übergreifenden Synchronisierung die zweite Karte benötigt wird, Hibiscus aber nicht pausiert, um dem Benutzer die Möglichkeit zu geben, die Chipkarte zu wechseln.

Ursache: Hibiscus erkennt nicht, *welche* Chipkarte eingelegt ist sondern nur *ob* eine eingelegt ist. Sobald eine Karte eingesteckt ist, wird der Vorgang fortgesetzt, auch dann wenn diese eventuell gar nicht zum aktuellen Konto passt.

Durch Erstellung/Anpassung einer Konfigurationsdatei lässt sich das jedoch einrichten:

• Wechsle in das Jameica-Benutzerverzeichnis
• Wechsle in das Unterverzeichnis „cfg“.
• Öffne dort die Datei mit dem Namen: „de.willuhn.jameica.hbci.passports.ddv.DDVConfig.properties“ in einem Texteditor (oder erstelle sie, falls sie noch nicht existiert).
• Füge folgende Zeilen hinzu:

waitfor.card.insert=true
waitfor.card.pin=false
waitfor.card.eject=false

Mit diesen drei Parametern kannst du selbst festlegen, in welchen Situationen Hibiscus beim Zugriff auf den Kartenleser pausieren soll.

• waitfor.card.insert: Wenn der Wert „true“ angegeben ist, zeigt Hibiscus vor dem Zugriff auf den Kartenleser ein Dialog-Fenster mit dem Text „Bitte legen Sie die Chipkarte in das Lesegerät“ an. Der Benutzer hat jetzt die Gelegenheit, die passende Karte einzulegen. Hibiscus setzt den Vorgang erst dann fort, wenn in dem Dialog-Fenster auf „OK“ geklickt wurde.
• waitfor.card.pin: Wenn der Wert „true“ angegeben ist, zeigt Hibiscus unmittelbar vor der PIN-Eingabe (nur bei Eingabe über das PIN-Pad des Kartenlesers) ein Dialog-Fenster mit dem Text „Bitte geben Sie die PIN in Ihren Chipkarten-Leser ein“ an. Die Eingabe der PIN startet erst dann, wenn der Benutzer im Dialog-Fenster auf „OK“ geklickt hat.
• waitfor.card.eject: Wenn der Wert „true“ angegeben ist, wird der Benutzer nach Beendigung des Zugriffs auf den Kartenleser explizit mit dem Dialog-Fenster „Bitte entfernen Sie die Chipkarte aus dem Lesegerät.“ aufgefordert, die Karten aus dem Leser zu entfernen. Der Vorgang wird erst fortgesetzt, wenn der Benutzer auf „OK“ geklickt hat - auch dann, wenn die Karte nicht aus dem Leser entfernt wurde.

Der Versuch, einen neuen INI-Brief in Hibiscus zu erstellen, endet in einer Fehlermeldung. In den Log-Ausgaben findet sich folgender (oder ähnlicher) Fehlertext:

9010: Schlüsseleinreichung wurde abgelehnt.

Das passiert, wenn bei der Bank bereits eine Schlüsseldatei hinterlegt ist. Man kann dann keine zweite mehr einreichen sondern muss vorher die bei der Bank hinterlegte löschen/zurücksetzen lassen.

Wende dich daher bitte an deine Bank und bitte sie darum, den dort hinterlegten Schlüssel zurücksetzen zu lassen und dir einen neuen INI-Brief zu senden. Bei manchen Banken muss man statt des Zurücksetzens auch eine neue Benutzerkennung beantragen (das ist von Bank zu Bank unterschiedlich). Erst dann kannst du in Hibiscus einen neuen INI-Brief erzeugen.

Achtung: Falls du bereits ein Bankingprogramm mit dem Verfahren Schlüsseldatei für diesen Bankzugang verwendest, dann stammt der bereits hinterlegte Schluessel eventuell von dort. Dieses Bankingprogramm würde danach dann nicht mehr funktionieren, weil man nur bei wenigen Banken mehrere unterschiedliche Benutzerkennungen mit getrennten Schlüsseldateien parallel verwenden kann.

Es kann auch sein, dass du den bereits bei der Bank hinterlegten Schlüssel selbst bei einem der ersten Versuche in Hibiscus (versehentlich) an die Bank übertragen hast. Da dieser Schlüssel danach aber nicht sofort funktionierte (denn den muss man anschliessend ja auch noch ausdrucken, unterschreiben, per Post/Fax an die Bank senden und ein paar Tage warten, bis die den freigeschaltet haben), hast du eventuell nochmal versucht, einen zu erstellen. Und das schlägt dann eben fehl, weil schon einer bei der Bank hinterlegt ist. Da du jetzt vermutlich nicht mehr nachvollziehen kannst, welcher Schlüssel deiner bisherigen Versuche jetzt bei der Bank liegt, ist es die sauberste Option, erst den bei der Bank löschen zu lassen und dann nochmal einen neuen INI-Brief zu erzeugen.

Problem: Die Schlüsseldatei stammt aus einem anderen Bankingprogramm und konnte in Hibiscus importiert werden. Beim Versuch, die Datei in Hibiscus zu öffnen oder sie zu verwenden, kommt es jedoch zu einer Fehlermeldung.

Ursache: Für das Dateiformat von Schlüsseldateien gibt es leider keinen herstellerübergreifenden Standard. Jeder Software-Hersteller „kocht da sein eigenes Süppchen“. Aus dem Grund ist es oft leider nicht möglich, die aus einem anderen Programm stammende Schlüsseldatei in Hibiscus zu importieren. Ebenso ist es sehr unwahrscheinlich, dass eine in Hibiscus genutzte Schlüsseldatei in einem anderen Programm verwendet werden kann.

Hibiscus enthält einen rudimentären Support für das Schlüsselformat „RDH2“, welches u.a. von Starmoney verwendet wird. Allerdings ist dieser Support schon einige Jahre alt. Es kann durchaus sein, dass die Hersteller das Dateiformat zwischenzeitlich ergänzt oder geändert haben und ein Import inzwischen nicht mehr möglich ist. Falls du es dennoch versuchen möchtest, dann wähle beim Import als Dateiformat „RDH-Format (StarMoney, ProfiCash, VR-NetWorld, Sfirm)“ aus. Klicke danach doppelt auf die Schlüsseldatei, um sie zu öffnen. Mit etwas Glück werden die Daten korrekt angezeigt und das Ausführen von FinTS-Geschäftsvorfällen funktioniert. Falls es zu einer Fehlermeldung kommt, bleibt hier nur noch die Möglichkeit, einen neuen INI-Brief in Hibiscus zu erzeugen, ihn auszudrucken und unterschrieben an die Bank zu senden (bei manchen Banken kann man den INI-Brief auch online per TAN einreichen), um eine neue Schlüsseldatei zu erzeugen. Beachte hierbei jedoch, dass der bereits bei der Bank hinterlegte erst zurückgesetzt/gelöscht werden muss (siehe Absatz „Schlüsseleinreichung wurde abgelehnt“ weiter oben). Das bewirkt jedoch auch, dass die vorherige Schlüsseldatei anschließend nicht mehr verwendet werden kann - auch nicht in dem ursprünglich genutzten Programm.

Seit Jameica 2.8.3 treten unter Umständen verschiedene Fehler bei der Darstellung der Anwendung auf. Das kann sie wie folgt äußern:

• Das grüne Symbol für geprüfte Umsätze wird in der Umsatzliste (Spalte „Flags“) nicht mehr angezeigt. Problem tritt nur auf, wenn diese Spalte als erste angezeigt wird. Verschiebt man die Spalte weiter hinter, werden die Symbole angezeigt
• Auf der Startseite wird eventuell die Summenzeile unter einer der Tabellen mit den Konten oder neuen Umsätzen nicht mehr angezeigt. Tritt ebenfalls nur dann auf, wenn die Tabelle auf der Startseite als erste angezeigt wird
• Nach dem Start des Programms reagiert die Anwendung sehr verzögert

Ursache: Jameica verwendet unter Linux seit Version 2.8.3 standardmäßig nicht mehr GTK2 sondern GTK3. Leider ist die GTK3-Unterstützung von SWT (SWT ist die Programmbibliothek, die von Jameica intern zur Darstellung der Benutzeroberflaeche verwendet wird. SWT stammt nicht von mir sondern von www.eclipse.org/swt) noch nicht ganz fehlerfrei. Der Workaround besteht darin, übergangsweise wieder zurück auf GTK2 zu wechseln. Das ist allerdings auch keine dauerhafte Loesung, weil GTK2 als veraltet gilt und in neuen SWT-Versionen (die aber noch nicht in Jameica enthalten sind) bereits nicht mehr unterstützt wird.

Öffne hierzu das Startscript „jameica.sh“ in einem Texteditor und ändere in der letzten Zeile das

SWT_GTK3=1

in

SWT_GTK3=0

Hierbei erscheint die Fehlermeldung

java.lang.NoSuchMethodError: gObjectClass_finalize

Das ist ein bekannter Fehler in SWT unter 32Bit-Linux. SWT ist die Programmbibliothek, die von Jameica intern zur Darstellung der Benutzeroberflaeche verwendet wird. SWT stammt nicht von mir sondern von www.eclipse.org/swt

Das Problem ist denen bekannt - https://bugs.eclipse.org/bugs/show_bug.cgi?id=527536 - wird allerdings nicht mehr behoben, weil in neuen SWT-Version ohnehin kein 32Bit-Support mehr enthalten ist.

Wechsle nach Möglichkeit auf die 64Bit-Version von Jameica. Beachte, dass du hierbei auch eine 64Bit-Version von Java benötigst und diese wiederum nur auf Computern mit 64Bit-Prozessor läuft.

Alternativ könntest als Workaround versuchen, auf GTK2 umzustellen. Das ist allerdings auch keine dauerhafte Lösung, weil GTK2 ebenfalls als veraltet gilt und in der aktuellen SWT-Version (die aber noch nicht in Jameica enthalten ist) ebenfalls bereits entfernt wurde. Siehe hierzu Darstellungsfehler unter Linux

Stattdessen funktioniert nur die 32Bit-Version von Jameica? Dann liegt das mit ziemlicher Sicherheit daran, dass du auf deinem Rechner ein 32Bit-Java (statt 64Bit-Java) installiert hast. Wichtig ist, dass Jameica- und Java-Version zusammenpassen. Ob es sich um ein 64Bit-Windows handelt, spielt dabei eine untergeordnete Rolle. Leider passiert es recht leicht, dass man auf einem 64Bit-Windows versehentlich ein 32Bit-Java installiert, weil auf http://www.java.com primär die 32Bit-Version verlinkt ist. Das 64Bit-Java findest du unter https://www.java.com/de/download/manual.jsp - wähle dort die Variante „Windows Offline“. Alternativ kannst du aber auch einfach das 32Bit-Java installiert lassen und stattdessen die 32Bit-Version von Jameica verwenden. Das funktioniert auch auf einem 64Bit-Windows.

Jameica muss mit dem Shell-Script „jameica.sh“ gestartet werden. Im Ubuntu-Desktop „Unity“ gibt es jedoch eine Funktion „Im Starter behalten“, mit der man eine laufende Anwendung im Programm-Menu „anpinnen“ kann. Das führt jedoch dazu, dass die in „jameica.sh“ definierten Umgebungsvariablen beim nächsten Start nicht mehr zur Anwendung kommen, da Ubuntu im Menu nicht den Aufruf von „jameica.sh“ selbst verknüpft sondern nur noch den daraus resultierenden Java-Aufruf. Die folgenden und notwendigen Umgebungsvariablen fehlen dann:

LIBOVERLAY_SCROLLBAR=0 GDK_NATIVE_WINDOWS=1 SWT_GTK3=0

Das führt zu bizarren Darstellungsfehlern und dem „Hängenbleiben“ der Anwendung.

Daher: Verwende nicht die Funktion „Im Starter behalten“ sondern lege die Programm-Verknüpfung manuell an, wie es im Ubuntu-Wiki beschrieben ist.

Siehe auch https://homebanking-hilfe.de/forum/topic.php?p=126800#real126800

Der Verbindungsaufbau zur Bank schlägt fehl. In der Log-Datei jameica.log findet sich die Fehlermeldung „java.net.ConnectException: Connection timed out: connect“ (im Forum findet sich hierzu ebenfalls eine Diskussion.

Mögliche Ursachen:

• Keine Internetverbindung vorhanden: Prüfe den Internetzugang auf deinem Computer bzw. Internet-Router.
• Bankserver offline: Es kann durchaus auch mal vorkommen, dass der Bankserver - zum Beispiel aufgrund von Wartungsarbeiten - tatsächlich mal nicht erreichbar ist. Sowas kann insbesondere Nachts oder an Wochenenden passieren. Versuche es einfach später erneut.
• Falsche Firewall-Einstellungen: Falls du auf deinem Computer oder auf deinem Internet-Router eine Firewall verwendest, prüfe deren Einstellungen. Stelle sicher, dass Jameica bzw. Java-Anwendungen Internetzugriff haben. Das ist eine häufige Ursache.
• Falsche Proxy-Einstellungen: Klicke im Menu auf „Datei>Einstellungen“ und überprüfe dort die Eingaben im Bereich „Proxy-Einstellungen“. Deaktiviere gegebenenfalls die Option „System-Einstellungen verwenden“.
• Falsche IPv6-Einstellungen: Ggf. ist dein Computer so konfiguriert, dass er versucht, das IPv6-Protokoll zu verwenden, die Bank unterstützt das jedoch nicht. Deaktiviere ggf. die IPv6-Unterstützung in deinem Betriebssystem. Wie genau das konfiguriert wird, hängt vom verwendeten Betriebssystem ab. Wende dich hierzu bitte an ein entsprechendes Support-Forum oder den Hersteller des Betriebssystems.
• IPv6 Java-Einstellungen: Ggf. ist auch Java selbst so konfiguriert, dass es versucht, den Bank-Server per IPv6 zu erreichen.
  • Wechsle in das Jameica-Benutzerverzeichnis
  • Wechsle in das Unterverzeichnis „cfg“.
  • Erstelle dort eine Datei mit dem Namen: „de.willuhn.jameica.services.SysPropertyService.properties“, falls sie noch nicht existiert.
  • Öffne die Datei in einem Texteditor und füge folgende Zeilen ein (beachte Gross-/Kleinschreibung):

java.net.preferIPv4Stack=true

Prüfe beim nächsten Start von Jameica anhand der Ausgaben in der Log-Datei jameica.log, ob das System-Property korrekt gesetzt wurde. Folge Meldung sollte in der Log-Datei erscheinen:

[<Datum>][INFO][de.willuhn.jameica.services.SysPropertyService.init] setting sys property: java.net.preferIPv4Stack: true

Beim Öffnen von Konten Aufträgen oder Kontoauszügen kommt es zu einem Fehler. Der Fehlertext sieht meist etwa so aus:

java.rmi.RemoteException: unable to init iterator. statement: .... nested exception is:
org.h2.jdbc.JdbcSQLException: Allgemeiner Fehler: java.lang.RuntimeException:
File ID mismatch got=0 expected=57 pos=5888 true org.h2.store.DiskFile:..../hibiscus/h2db/hibiscus.data.db blockCount:0
General error: java.lang.RuntimeException: File ID mismatch got=0 expected=57 pos=5888 true

Die Hibiscus-Datenbank hat einen Defekt. Das kann z.Bsp. durch Schreibfehler auf der Festplatte oder einen Absturz passieren.

Abhilfe

Erstelle auf jeden Fall erstmal eine Sicherheitskopie des Jameica-Benutzerverzeichnisses. Siehe Backups erstellen. Es existieren mehrere alternative Lösungsmöglichkeiten:

1. Backup einspielen

• Klick in Jameica im Menu auf „Datei→Backups verwalten…“
• Wähle dort das Backup von dem Zeitpunkt aus, zu dem es noch funktionierte.
• Klicke auf „Backup wiederherstellen“
• Beim nächsten Start von Jameica wird das Backup automatisch eingespielt.

2. Datenbank reparieren

Insbesondere dann hilfreich, wenn kein funktionierendes Backup mehr vorhanden ist:

• Öffne die Konfig-Datei „de.willuhn.jameica.hbci.rmi.HBCIDBService.properties“ in einem Texteditor. Die Datei befindet sich im Unterverzeichnis „cfg“ des Jameica-Benutzerverzeichnisses. Also z.Bsp. in „C:\Users\<username>\.jameica\cfg“ oder „/home/<username>/.jameica/cfg“

• Füge dort folgende Zeile hinzu (bzw. ändere deren Wert von „false“ auf „true“, falls die Zeile bereits existiert):

database.driver.h2.recover=true

• Starte nun Hibiscus neu

Der Parameter bewirkt, dass die Datenbank einen internen Reparatur-Mechanismus startet. Wenn die Reparatur erfolgreich verlief, dann beende Hibiscus und ändere den Parameter wieder auf „false“.

3. Diagnose-Backup

• Klicke im Menu auf „Hibiscus→Erweitert→Diagnose-Backup erstellen…“. Hierbei wird ein XML-Dump der Hibiscus-Datenbank erstellt.
• Beende Hibiscus.
• Benenne nun das Jameica-Benutzerverzeichnis „.jameica“ um oder verschiebe es an einen anderen Ort.
• Starte Hibiscus neu. Hierbei wird ein neues Masterpasswort vergeben und eine neue leere Hibiscus-Datenbank erstellt.
• Klicke nun im Menu auf „Hibiscus→Erweitert→Diagnose-Backup importieren…“ und wähle hier den erstellten XML-Dump aus.
• Die HBCI-Sicherheitsmedien (PIN/TAN, Schlüsseldiskette oder Chipkarte) müssen jetzt jedoch manuell nochmal neu angelegt werden.

Generell

Eventuell kann das Problem auch durch einen Fehler in der von Hibiscus intern verwendeten Datenbank-Software H2 ausgelöst werden. Das konnte bisher nicht völlig ausgeschlossen werden. Daher ist es generell sinnvoll, immer die aktuellste Hibiscus-Version zu nutzen, da dort auch jeweils eine aktuelle Version der H2-Datenbank enthalten ist.

Mögliche angezeigte Fehlermeldungen:

• Algorithm [JKS] of type [KeyStore] from provider [org.bouncycastle.jce.provider.BouncyCastleProvider: name=BC version=1.24] is not found
• java.lang.SecurityException: write access to /opt/jameica/jameica.lock denied„
• java.lang.RuntimeException: java.security.KeyStoreException: JKS

Dieser Fehler tritt meist bei Debian-basierten Distributionen (z.Bsp. Ubuntu, Kubuntu) auf. Diese verwenden standardmässig nicht SUN Java sondern GNU Java (gcj). Jameica funktioniert damit leider nicht. Suche im Paket-Manager nach „SUN Java“ oder „OpenJDK“. Für Ubuntu heisst das Paket „sun-java6-jre“.

Gib anschließend als User „root“ auf einer Konsole

update-alternatives --config java

ein. Es werden die installierten Versionen von Java aufgelistet. Dort die „sun“ Version heraussuchen, die entsprechende Ziffer eingeben und bestätigen.

Auf dem Computer ist Java nicht installiert oder der Befehl „java“ wurde nicht gefunden. Lade Java z.Bsp. von http://www.java.com herunter und installiere es. Anschliessend sollte der Befehl „java“ gefunden werden.

Hierbei handelt es sich um sog. „Sicherheitsprofile“, die ab der HBCI-Version „FinTS“ unterstützt werden. HBCI4Java versucht diese mit an die Bank zu senden. Unterstützt die verwendete HBCI-Version dies jedoch noch nicht, werden diese Warnungen im Log-Fenster angezeigt. Die Meldungen sind völlig harmlos und können ignoriert werden.

Falls Überweisungen mit einem HBCI-Account bei der 1822direkt Sparkasse fehlschlagen, kann dies an der „falschen“ Bankleitzahl liegen. Es muss die alte Bankleitzahl (eigentlich die der Frankfurter Sparkasse) eingestellt werden. Die folgenden Bankleitzahlen zur 1822direkt Sparkasse gibt es:

• 500 502 22 (die neue Bankleitzahl)
• 500 502 01 (die alte Bankleitzahl, eigentlich Frankfurter Sparkasse)

Falls kein Zugriff auf die Ing-Diba möglich ist, kann es an der Anzahl der Stellen der PIN oder der Kundenkennung liegen. Die Webanwendung der Bank und StarMoney 8.0 unterstützen längere Zeichenketten, daher sollte vor einem Umstieg folgendes geprüft werden:

1. Nummerierter Listenpunkt. Die Länge der Kundenkennung (max. 10-Stellen bei FIN-TS 3.0)
2. Die Länge der PIN (max. 10 Stellen bei FIN-TS 3.0)

Ggf. muss die PIN in der Webanwendung der Bank vorher in eine kürzere (max. 10 Stellen) lange PIN geändert werden.

Weitere Informationen zur Einrichtung befinden sich unter: ING-DiBa: PIN/TAN

Die Postbank stellt die Bankzugänge beginnend ab Herbst 2018 auf das neue Login per „Postbank ID“ um. In der Liste der bankspezifischen Informenen im Wiki finden sich hierzu weitere Informationen.

Scheinbar unaufgefordert erscheint ein Dialog mit dem Betreff „Sicherheitsabfrage“ und dem Text „Bitte prüfen Sie die Eigenschaften des Server-Zertifikates und entscheiden Sie, ob Sie ihm vertrauen möchten.“.

Das angezeigte Zertifikat ist in der Regel von der „Organisation (O)“:„Let's Encrypt“ (https://letsencrypt.org/) ausgestellt und für unterschiedliche „Common Name (CN)“ wie etwa https://www.willuhn.de, https://bursch.com, https://scripting-updates.derrichter.de/ ausgestellt.

Ursache: Jameica besitzt einen integrierten Plugin-Manager, mit dem neben Hibiscus auch andere Plugins online installiert oder aktualisiert werden können. Klicke oben im Menü auf „Datei→Einstellungen→Plugins“, um den Plugin-Manager zu öffnen. Dort findet du unten einen Button „Repositories bearbeiten…“ sowie „Automatische Updates konfigurieren…“. Ein Klick auf „Repositories bearbeiten…“ öffnet eine Liste von Servern, über die Jameica-Plugins bezogen werden können. Meist sind dies:

(siehe auch: Liste der bekannten Plugins)

Ein Klick auf „Automatische Updates konfigurieren…“ öffnet die Konfiguration, mit der festgelegt wird, ob und in welchen zeitlichen Abständen Jameica automatisch nach Updates auf oben genannten Adressen sucht.

Da die Zertifikate von „Let's Encrypt“ nur eine Gültigkeit von 3 Monaten haben, müssen sie regelmäßig aktualisiert werden. Es kann daher immer mal wieder vorkommen, dass Jameica die Zustimmung für Zertifikate erfragt, die kürzlich aktualisiert wurden. Im Regelfall sollte Jameica die Gültigkeit der Zertifikate selbst automatisch prüfen können. Allerdings verwendet „Let's Encrypt“ für einen Übergangszeitraum sogenanntes „Cross Signing“. Unter https://letsencrypt.org/2020/09/17/new-root-and-intermediates.html wird das Thema näher beleuchtet (Achtung, sehr komplex). Die Server-Zertifikate der oben genannten URLs sind hierbei mit zwei verschiedenen Aussteller-Zertifikaten von „Let's Encrypt“ unterzeichnet. Je nach verwendeter Java-Version oder Betriebssystem kann es vorkommen, dass die automatische Prüfung des Aussteller-Zertifikates fehlschlägt (wenn die Java-Version oder das Betriebssystems Cross-Signing nicht unterstützt oder im Stammzertifikatsspeicher nicht beide Aussteller-Zertifikate von „Let's Encrypt“ enthalten sind). In genau diesem Fall zeigt Jameica die Sicherheitsabfrage an, um dem Benutzer die manuelle Prüfung des Zertifikates zu überlassen.

Diese manuelle Prüfung kann im Regelfall wie folgt durchgeführt werden:

1. Kopiere die im Zertifikat angezeigte Server-Adresse und gib sie im Browser ein. Ob hierbei die Webseite des Plugin-Autoren, eine Platzhalter-Seite oder einfach nur eine leere Seite angezeigt wird, spielt keine Rolle.
2. Klicke in der Adress-Zeile des Browsers auf das Schloss-Symbol, um die Details des Zertifikats anzuzeigen.
3. Die dort angezeigten Informationen (hier insbesondere die SHA-256-Prüfsumme) sollten mit den in Jameica angezeigten Informationen übereinstimmen.

Plugin-Repositories deaktivieren: Wenn du von einigen der oben genannten Bezugsquellen keine Plugins verwendest, kannst du die Server-Adressen auch deaktivieren. Klicke hierzu auf „Repositories bearbeiten…“. Klicke mit der rechten Maustaste auf die zu deaktivierenden URLs und wähle im Kontextmenü „Deaktivieren…“. Die URL wird anschließend in grauer Textfarbe angezeigt. Jameica wird diese Seiten dann nicht mehr kontaktieren und daher auch keine Sicherheitsabfragen zu diesen URLs mehr anzeigen.

Beim ersten Start von Jameica wird ein SSL-Zertifikat mit Private- und Public-Key nach dem X.509-Verfahren erzeugt. Der Schlüssel hat eine Länge von 2048 Bit und nutzt das RSA-Verfahren. Beide Schlüsselhälften werden in einem „Java-Keystore“ (“.jameica/cfg/jameica.keystore„) gespeichert. Dieser wiederum wird mit dem beim Jameica-Start eingegebenen Master-Passwort geschützt. Die Keystore-Datei besitzt das SUN-eigene „JKS“-Format und kann auch mit dem SUN keytool geöffnet werden. Dieses Schlüsselpaar bildet zusammen mit dem Master-Passwort die technische Grundlage für die von Jameica/Hibiscus selbst verschlüsselten Daten.

Die Benutzerdaten werden wie folgt gespeichert:

• PINs oder Passwörter der HBCI-Verfahren „Chipkarte“ (hier nur bei Eingabe über die PC-Tastatur) oder „Schlüsseldatei“ werden nicht auf der Festplatte gespeichert sondern höchstens für die Dauer der Sitzung (falls die entsprechende Option im Menu unter Hibiscus→Einstellungen aktiviert wurde) verschlüsselt im Speicher gehalten. Die Verschlüsselung hierbei erfolgt mit einem RSA-Cipher, gesichert mit dem oben genannten Public-Key. Da das Ver- und Entschlüsseln mit diesem asymmetrischen Verfahren verhältnismäßig langsam ist, wird es nicht für die Speicherung größerer Datenmengen genutzt sondern nur für „kleine Daten“ wie PINs und Passwörter.

• Chipkarten-PINs, die über die Tastatur des HBCI-Kartenlesers eingegeben werden, gelangen nicht in den Computer (die komplette PIN-Prüfung geschieht direkt im Kartenleser) und werden daher auch in keiner Weise irgendwo gespeichert.

• PINs des HBCI-Verfahrens „PIN/TAN“ können optional (wenn dies im Menu unter Hibiscus→Einstellungen aktiviert wurde) in der Wallet-Datei “.jameica/cfg/de.willuhn.jameica.hbci.HBCI.wallet2“ permanent gespeichert werden. Die Verschlüsselung hierbei erfolgt nach dem gleichen Verfahren wie bei der Zwischenspeicherung für die Dauer der Sitzung (RSA-Cipher via Public-Key des Jameica-Zertifikates). Die Option zum permanenten Speichern von PINs des PIN/TAN-Verfahrens unter Hibiscus→Einstellungen lässt sich nur aktivieren, wenn das Master-Passwort manuell beim Start eingegeben wurde (also nicht via Startparameter “-p„ übergeben wurde).

• Sensible Daten von HBCI4Java wie HBCI-Schlüsseldisketten oder UPDs von PIN/TAN-Passports werden mit dem Cipher-Algorithmus „AES-256“ verschlüsselt. Als Passwort dient hier ein vom Benutzer manuell einzugebendes (bei Schlüsseldisketten) oder ein von Hibiscus zufällig erzeugtes (bei PIN/TAN), welches in der Wallet-Datei “.jameica/cfg/de.willuhn.jameica.hbci.HBCI.wallet2„ gespeichert wird. Die Wallet-Datei ist mit einem RSA-Cipher (basierend auf dem o.g. Jameica-Systemzertifikat) geschützt.

• Sensible Daten wie Konten, Umsätze usw. werden in der (falls nicht explizit MySQL konfiguriert wurde) internen H2-Datenbank von Hibiscus gespeichert. Sie nutzt den XTEA-Algorithmus (mit 32 Runden) zur Datenverschlüsselung. Weitere Details hierzu finden sich in der H2-Dokumentation.

• Nicht sensible Daten wie Layout-Informationen der Benutzeroberfläche werden unverschlüsselt in Form von Properties-Dateien im Verzeichnis “.jameica/cfg„ abgespeichert.

In den Standard-Einstellungen prüft Hibiscus die Echtheit des SSL-Zertifikates des Bank-Servers zuerst über die Liste der in Java enthaltenen Aussteller-Zertifikate. Kann es über diese Liste nicht geprüft werden (weil kein passendes Aussteller-Zertifikat enthalten ist), zeigt Hibiscus einen Hinweis-Dialog an, über den der Benutzer dem Zertifikat manuell vertrauen kann. Zusäzlich prüft Hibiscus den Gültigkeitszeitraum des Zertifikates sowie den Hostnamen, auf den das Zertifikat ausgestellt ist.

Wenn du ganz auf Nummer sicher gehen möchtest, kannst du unter „Datei→Einstellungen→System“ die Option „Den Aussteller-Zertifikaten von Java vetrauen“ deaktivieren. Nach einem Neustart prüft Hibiscus das Server-Zertifikat nicht mehr über die in Java enthaltenen Zertifikate sondern ausschließlich über die Zertifikate, denen du explizit vertraust. Das hat zur Konsequenz, dass auch dann ein Warnhinweis angezeigt wird, wenn das Server-Zertifikat der Bank zwar von einer anerkannten Zertifizierungsstelle (wie Thawte, Verisign, o.ä.) ausgestellt wurde, du dem Zertifikat aber noch nicht explizit vertraut hast (durch Klick auf „Ja“ in diesem Warnhinweis). Die Option sollte nur deaktiviert werden, wenn man weiss, wie man Zertifikate manuell (anhand des Finger-Abdruckes) prüfen kann.