Beiträge von gdrexl

    Nachdem ich vor einer Woche einen Hotfix für die EÜR zu diesem Problem vom Entwickler getestet und freigegeben habe, hat mich der Buhl Kundenservice gestern per Mail informiert,

    Zitat

    dass mittlerweile eine Lösung zu Ihren Sachverhalten erarbeitet werden konnte. Die Umsetzung erfolgt in einem der kommenden Updates.

    in einem der kommenden Updates...

    Geht jetzt nun irgendwie ein Zugang um das Konto einzurichten?

    Mit der aktuellen Version 14.03 (Build 1609) geht es, aber nicht ganz so wie Buhl es sich vorstellt...


    Wenn man in der Maske von #1 einen beliebigen Pfad auswählt und irgendetwas in das Passwortfeld schreibt und danach auf "Kontakt mit neuer Schlüsseldatei erstellen", dann kommt man auf den DDBAC-Dialog und kann dort auswählen, ob man eine neue Schlüsseldatei erstellen oder eine vorhandene Schlüsseldatei auswählen will. Die Folge-Masken durchlaufen und schon funktioniert es.


    Die Bewegungen lassen sich bei mir danach problemlos einlesen.


    Der Fehler in den Buhl-Masken wird bereits bearbeitet. Einen ersten Hotfix musste ich aber zurückweisen, da damit ein anderer Fehler auftrat.


    Viele Grüße

    Gerhard

    Naja...


    Hier ist es tatsächlich komplizierter, trotzdem wurde das Ticket über Wochen hinweg überhaupt nicht bearbeitet. Jetzt ist einzig auf errjot's Initiative Bewegung in die Sache gekommen.


    Die "Commerzbank" liegt aber schon genauso lange auf Halde. Hier war es ein ganz simpler Fehler (statt Dialog "Datei auswählen" wurde der Dialog "Verzeichnis auswählen" aufgerufen). Der Fehler wurde binnen kurzer Zeit gefunden (< 1 Tag), das Fixing wird heute getestet und geht danach in den Rollout. Der Support hat das Ticket aber nicht beachtet, sondern es sogar mehrfach ohne Begründung geschlossen.


    Mag sein, dass der Support "normalerweise" richtig und gut funktioniert. Hier in diesen beiden Fällen gibt es aber - vielleicht durch die PSD2-Umstellung bedingt - durchaus ordentlich Luft nach oben.

    Hallo Billy,


    es ist durchaus sinnvoll, von der "robusten, bewährten und einfachen DDBAC"-Vorgehendweise bzgl. Datenhaltung abzugehen. Zum einen ist es aus Datenschutzgründen nicht besonders prickelnd, wenn die Kontakte da offen liegen.

    In den DDBAC-Daten ist eigentlich nur die IBAN in Klartext enthalten. Pins o.ä. werden nicht abgespeichert. Wenn es daher ein Risiko im Hinblick auf den Datenschutz geben sollte, so hätten die B+S Banksysteme Ag und alle, die diese Komponenten direkt verwenden, längst Alarm geschlagen. Daten kann man übrigens auch einfach und robust in der Datenbank halten. Ich hatte gerade mit dem verantwortlichen Entwickler von Buhl Kontakt. Er sagte mir, dass Buhl mehr Banken einbinden, als die DDBAC dies tut und deshalb eine weitere Kapselung erfolgt ist.

    Zum anderen verfolgt Buhl offensichtlich die Strategie, die LetsTrade-Onlinebanking-Komponenten (aktuell LT5) in allen Programmen einzubauen, um eine firmenweite Einheitlichkeit herzustellen.

    Dieses Problem liegt ja eben nicht in den LetsTrade-Onlinbanking-Komponenten, sondern in der Datenspeicherung und die ist offenbar von Programm zu Programm unterschiedlich. Das Raiffeisenbank-Konto lässt sich ja problemlos in Mein Geld einrichten, nicht aber im Hausverwalter. Wie Du in einem meiner älteren Beiträge nachlesen kannst, bin ich ja gerade für eine Zentralisierung und Wiederverwendung von ausgetesteten Modulen. (Ich bin im Moment zu faul, den Betrag herauszusuchen, mache es aber bei Bedarf gerne...)

    Und wenn diese Kontakte in der Datenbank gespeichert werden, dann hat das Vorteile beim Umzug auf einen anderen Rechner (Datenbank kopieren - fertig) und bei mobilen Programmversionen (z.B. Mein Geld Stick-Installation).

    Eine Datenbankdatei kopieren ist besser und einfacher einen Ordner kopieren...? Versteh ich nicht.


    Mag ja sein, daß Dich das alles nicht sonderlich interessiert, weil Du auf Dein Programm fokussiert bist

    Ich nutze Microsoft Money, Lexware Taxman, Buhl EÜR+Kasse, Buhl Hausverwalter 2020, Buhl Hausverwalter 2019 und habe Mein Geld bis zum Auslaufen der Test-Periode getestet. Alle mit DDBAC und/oder LetsTrade. Was meinst Du mit "Dein Programm"?


    Was die anderen technischen Kritikpunkte anbelangt, damit sollten sich die Entwickler befassen. Das Forum ist nicht der Ort dafür

    … ist heute geschehen, nachdem ein Forumsmitglied mit entsprechenden Kontakten das angeleiert hat. (Vielen Dank an dieser Stelle nochmal dafür!) In einem sehr netten Gespräch mit dem Entwickler hat sich herausgestellt, dass der Kundenservice die Tickets bisher liegen gelassen hat. Morgen bekomme ich eine Testversion für das Commerzbank-Problem und für das Raiffeisenbank-Problem stelle ich die entsprechenden Datenbankeinträge zur Analyse zur Verfügung. Wie gesagt, das ging alles über die Forumseinträge und hat über den Kundenservice überhaupt nicht funktioniert. Der Entwickler hat sich über meine präzisen Angaben gefreut, sie als hilfreich eingestuft und sich dafür bedankt.


    leistest Du jetzt eigentlich Support, wenn sich andere Anwender ihre Datenbanken zerschießen, wenn sie versuchen, nach Deinen Beschreibungen auch etwas zu reparieren?

    Die Datenbank ist - wie Du weißt - mit einem Passwort geschützt. Dieses habe ich nicht weitergegeben. Dass es sich um eine Access-Datenbank handelt, hast Du auch schon anderweitig erwähnt. Wenn also jemand diese Datenbank öffnen und verändern kann, sollte er auch wissen was er tut, bzw. wie er vorgeht. Und sollte doch etwas passieren und derjenige tatsächlich nicht auf einer Test-Umgebung gearbeitet haben, so kann er sein letztes Backup einspielen. Wer weder in einer Test-Umgebung noch mit Backup arbeitet und trotzdem seine Datenbank zerschießt braucht keinen Support. Weder von mir, von Buhl oder von sonst wem... Der Elektriker haftet auch nicht, wenn jemand mit Metall-Stricknadeln in der Steckdose bohrt.


    Viele Grüße

    Gerhard

    So! Jetzt ist Buhl am Zug.

    Auf Basis von Spekulationen? Bei allem Respekt - da verlangst Du ziemlich viel.

    Ach Billy!


    Was verlange ich denn? Ich verlange lediglich, dass ein kommerziell vertriebenes Produkt die zugesagten Eigenschaften auch liefert. So weit ich weiß, steht mir dieses Recht laut Gesetz zu. Wie Buhl das hinbekommt ist mir eigentlich egal. Es wäre nur nett, wenn die aufgezeigten Mängel endlich behoben werden würden. Das Ticket ist immer noch offen.


    Ein kundenorientiertes Unternehmen und interessierte Entwickler sind für alle sachdienlichen Hinweise immer dankbar. Für den Entwickler mit Source-Code ist es eine Sache von wenigen Minuten, zu prüfen ob an fraglicher Stelle festverdrahtete Satzlängen verwendet werden oder nicht. Mich würde diese Prüfung Monate oder gar Jahre kosten, da ich keinen Zugriff auf die Sourcen habe, müsste ich das Programm dekompilieren und analysieren. Daher kann ich nur - so wie ich geschrieben habe - aufgrund meiner Erfahrungen und Beobachtungen spekulieren. Ob meine Annahmen plausibel sind oder nicht, kann ja jeder für sich beantworten.


    Letztendlich ist der Beitrag nur ein Angebot zur Unterstützung. Buhl kann beim Bugfixing nur Geld sparen, wenn sie den Hinweisen nachgehen. Wenn sie den Fehler anderweitig beheben ist mir das auch recht.


    Wo siehst Du Leserzahlen? Ich sehe nur Zugriffe ...

    Da hast Du wohl recht! Sorry! Mein Fehler! Ich ging davon aus, wenn jemand die Seite aufruft, liest er sie auch. Kann sein, dass da auch Suchmaschinen-Bots mitgezählt werden... ich weiß es nicht.


    Der normale Anwender wird sich kaum damit befassen.

    Der "normale" Anwender ist daran interessiert, dass die gekauften Produkte so wie beschrieben funktionieren. Mancher ist daran interessiert, wie etwas funktioniert, mancher will es vielleicht genauer wissen. Wen es interessiert, der soll es lesen, die anderen sollen überblättern.


    Bei Deiner Antwort fällt auf, dass Du die eigentlichen Aussagen und Argumentation komplett ignorierst. Du kritisierst nur ein paar unwichtige Randbemerkungen.


    Viel Grüße

    Gerhard

    Beim Neueintrag mußt Du natürlich zuerst die Checkbox aktivieren und dann den Zählerstand eintragen. Sonst wird normal gerechnet und die nachträgliche Aktivierung der Checkbox ändert daran nichts.

    Bei allem Respekt! "natürlich" ist das mit Sicherheit nicht. Das Programm muss bei der Datenübernahme (eventuell erneut) rechnen! Das Ergebnis darf nicht von der Reihenfolge der Bedienung von gleichberechtigten Controls abhängen! Ist eine zwingende Reihenfolge erforderlich, so muss diese vom Programm verbindlich vorgegeben werden!

    Hallo zusammen,


    Nachdem sich - wie die Leserzahlen zeigen - doch einige für das Thema interessieren und das gleiche Problem offenbar auch bei der Postbank auftritt, lege ich hier noch einen drauf. Hierbei handelt es sich aber um eine reine Spekulation, die nur auf meinen Beobachtungen und Erfahrungen beruht:


    Bei der Konfiguration zum Online-Zugang eines Bankkontos schreibt Buhl sämtliche von LetsTrade ermittelten Daten für alle Konten in eine Datei und speichert diese in der Tabelle "LetsTrade". Hierbei ist eine korrekte Ermittlung der Anzahl aller zu speichernden Parameter, sowie deren Platzbedarf von grundlegender Bedeutung. Liegt man hier falsch, so landen die Daten teilweise nur verstümmelt in der Datenbank und sind somit unbrauchbar.


    Hier nun meine Spekulation: Der Hausverwalter ermittelt beim Speichern die Parameterzahl und Satzlängen nicht zur jeweiligen Laufzeit, sondern verwendet zumindest teilweise fest verdrahtete (zur Entwicklungszeit der Routine festgelegte) Werte.


    Folgt man dieser Spekulation, so hätte dies folgenden Auswirkungen:


    • Das Programm hat vormals korrekt gearbeitet.
    • Bei den PSD2-Umstellungen hat sich in vielen Fällen die Anzahl der Konfigurationsparameter und deren Größe verändert. Die Online-Komponenten (DDBAC und LetsTrade) wurden daraufhin unter Hochdruck angepasst, an die feste Datensatzlänge in den Speicher-Routinen des Hausverwalters hat aber in der Hektik vermutlich keiner gedacht. Deshalb schreibt die Routine teilweise nur Datenmüll in die Datenbank.
    • Andere Programme mit anderer Datenhaltung wie z.B. mein Geld können mit den gleichen Online-Komponenten die Konfigurationsdaten korrekt speichern.
    • Der Kundenservice tut sich schwer: Die Online-Komponenten wurden immer wieder verändert, die ehemals funktionierenden Zugriffsroutinen wurden dagegen nicht angefasst. Da liegt der Trug-Schluss nahe, dass ein neu aufgetretener Fehler in den Online-Komponenten liegen muss. Die Folge davon: Man sucht an komplett falscher Stelle, das Ticket wird in eine falsche Schublade gesteckt, der Kunde wird nicht ernst genommen, da er ja keine Ahnung hat...

    Fazit:

    fest verdrahtete Satzlängen beim Speichern der LetsTrade-Konfigurationsdaten sind eine einfache und logische Erklärung für die gesamte geschilderte Problematik.


    So! Jetzt ist Buhl am Zug. Mehr Information und Zuarbeit kann man - denke ich - von einem zahlenden Kunden nicht erwarten.


    Viele Grüße

    Gerhard


    PS: ich hoffe, dass diese technischen Erläuterungen nicht zu viel für ein Anwenderforum sind...

    Respekt, Gerhard, für Deine Beharrlichkeit und IT Fachkenntnis, so etwas auszuspüren.

    Danke für die Blumen, aber so wild ist das nicht. Nur ganz normales Tagesgeschäft...

    wir sind so unwichtig das kein Mod sich diesem Forum annimmt....

    Mindestens ein Mod hat den Beitrag gelesen. Und sogleich seinem Missfallen durch eine offizielle Verwarnung Ausdruck verliehen... Wegen "nicht hinnehmbarer Spitzen"... :(

    Bei der WEG-Verwaltung gehört mir als Verwalter das Hausgeldkonto auch nicht, sondern wird nur von mir verwaltet. Die Einnahmen und Ausgaben auf diesem Konto gehören auch nicht zu meinen Einnahmen/Ausgaben. Trotzdem werden sie über Einnahmen/Ausgaben gebucht und nicht in den Stammdaten. Nach o.g. Argumentation dürfte es dann auch nicht so sein...


    Aber egal. Ich weiß, dass ich Kautionen und WEG-Vermögen von meinem persönlichen Vermögen getrennt halten muss, was schon alleine durch die unterschiedlichen Konten und Kontoinhaber gegeben ist. Und ich kann/muss mit diesen Ungereimtheiten im Hausverwalter leben. Ich muss nicht alles auf dieser Welt verstehen.... ;)

    Wie ich die Kautionen im Hausverwalter buchen muss, habe ich - Dank eurer Hilfe - verstanden. Ich fände es vom Aufbau aber immer noch logischer, wenn alle Konfigurationen um Bereich "Stammdaten" und alle Buchungen im Bereich "Einnahmen/Ausgaben" erfolgen würden.

    Hallo zusammen,


    irgendwie kommt Buhl auf der einen Seite mit der Fehlerbereinigung nicht weiter und mir lässt das Ganze auf der anderen Seite keine Ruhe, da ich die bezahlte Funktionalität des Programmes auch nutzen will. Deshalb habe ich nun nochmal tiefer gegraben:


    DDBAC speichert bei der Standard-Installation seine Konfigurationsdaten unter C:\Users\[user]\AppData\Roaming\DataDesign\DDBAC mit je drei Dateien für jeden HBCI-Kontakt (*.upd, *.bpd, *.spa). Die Datenhaltung ist hier also denkbar einfach und robust.


    Buhl hat sich nun entschieden, nicht den erprobten Standard-Weg zu gehen, sondern ein eigenes Süppchen zu kochen. Im Hausverwalter werden die HBCI-Kontakte in der Datenbank gespeichert. Hierfür gibt es extra eine Tabelle "LetsTrade". In dieser Tabelle gibt es neben einer LetsTradeID die Felder TechDB und TechDB1 bis TechDB9. Es ist nur ein Datensatz mit der LetsTradeID "1" vorhanden und nur das Feld TechDB ist gefüllt. Das Feld TechDB ist ein Langer Text und enthält auf den ersten Blick eine wirre Zeichenfolge.


    Probehalber habe ich in der Kopie diesen einen Datensatz gelöscht. Nun zeigte der Hausverwalter bei allen Online-Konten die bekannte Fehlermeldung "Das Konto mit der IBAN DE... konnte nicht ermittelt werden. Bitte richten Sie den Online-Zugang für das Konto erneut ein." an. Ich war also auf der richtigen Spur.


    Wenn man sich den Inhalt des Feldes "TechDB" der Tabelle (bei mir ca. 50 KB) genauer ansieht, scheint dieses MIME-codiert zu sein. Und siehe da, mit einem base64-Decoder sieht man am Anfang der Daten den Kontonamen in Klartext. Für mich sieht das nun so aus, als habe Buhl statt die millionenfach bewährten Zugriffsmechanismen der Access-Datenbank zu nutzen, die DDBAC-Konfigurationen mit eigenen Zugriffsmechanismen in eine eigene Datendatei gepfriemelt, und diese Datendatei dann codiert im Feld "TechDB" die Access-DB abgelegt. Dabei hat Buhl hier auch die Vorteile einer relationalen Datenbank mit Primär- und Fremdschlüsseln komplett ignoriert und eine eigene Lösung mit Suchen und Finden gebastelt, was letztendlich leicht zu Inkonsistenzen beim Bearbeiten und Löschen einzelner Datensätze führt.


    Ich habe nun die Tabelle "LetsTrade" aus meiner funktionierenden Hausverwalter 2019 Test-Datenbank in die Datenbank des Hausverwalters 2020 kopiert. Und siehe da: Problem gelöst. Auch der Hausverwalter 2020 findet nun das Raiffeisenkonto und kann die Umsätze problemlos einlesen.


    Somit ist klar gezeigt, dass der Fehler in der HBCI-Konfigurations-Datenhaltung des Hausverwalters liegt. Genauer gesagt ist die Buhl'sche "Schreiben-Routine" der HBCI-Konfiguration fehlerhaft.


    Es bleibt mir absolut unverständlich, warum Buhl nicht die millionenfach erprobten Standardlösungen nutzt sondern dafür fehlerhafte Basteleien einsetzt und dann obendrein über Wochen und Monate nicht in der Lage/willens ist, die Fehler in den unnötigen Eigenentwicklungen zu finden und zu beseitigen. Diese Vorgehen ist absolut fragwürdig und steigert nicht eben mein Vertrauen in die Buhl'sche Datenhaltung im Allgemeinen. (Den letzten Satz habe ich 3x durch den Weichspüler geschickt, damit sich empfindlichen Mod-Seelen nicht daran stören;))


    Viele Grüße

    Gerhard

    Und die Buchungen auf das Kautionskonto (Eingang, Zinsen, Zinsabschlag, Soli...) erfolgen dann im Bereich "Stammdaten" statt wo ich es erwarten würde im Bereich "Einnahmen/Ausgaben"? Gibt es dafür eine fachliche Erklärung?

    Viele Grüße

    Gerhard