- New
- Official Post
ODBC ist etwas für eine reine Datenbank nicht für eine Buchhaltung.
Deswegen ist eher eine REST-API die bessere Schnittstelle.
ODBC ist etwas für eine reine Datenbank nicht für eine Buchhaltung.
Deswegen ist eher eine REST-API die bessere Schnittstelle.
Wir drehen uns bei dem Thema im Kreis ohne, dass der Kreis sich schließt.
ODBC ist etwas für eine reine Datenbank nicht für eine Buchhaltung.
Deswegen ist eher eine REST-API die bessere Schnittstelle
aber, es gibt trotz Terminankündigung "ca. im Oktober 2025" bis heute keine.
Bislang wird dem Wunsch wohl nachgegangen, doch scheint keine neue Info zum Stand verfügbar zu sein und neue Vermutungen zu Terminen - die nur Verägerung bringen, wenn sie nicht gehalten werden können - werden vernünftigerweise nicht mehr genannt.
Kurz gesagt: Der Verbesserungsvorschlag, wird wohl per REST-API angegangen ohne dass ein Zeitraum wirklich planbar ist.
Kurz gesagt: Der Verbesserungsvorschlag, wird wohl per REST-API angegangen ohne dass ein Zeitraum wirklich planbar ist.
So wird es wohl in der Tat sein. Das Problem, jedenfalls fuer mich, ist, dass die Welt nicht stehenbleibt und eine FiBu ohne vernuenftige API ein echtes Problem darstellt. Ich habe mir als Uebergangsloesung etwas gebaut, aber das ist auf Dauer keine Loesung. Ich mag Taxpool und wuerde gerne dabei bleiben. Es wird fuer mich aber zunehmend schwierig, was schade ist.
und eine FiBu ohne vernuenftige API ein echtes Problem darstellt.
Schlimmer finde ich die Programme, die zwar eine API anbieten, aber eben keine vernünftige FiBu und dann auch noch zu Preisen, die ich für die gebotene Leistung nicht für angemessen halte.
Übergangslösungen sind ja oft jene, die am längsten genutzt werden. ![]()
Dass die API ausgerechnet bei Taxpool vermisst wird kann ich nachvollziehen. Es ist halt ein konkurrenzlos günstiges und doch vollständiges Buchhaltungsprogramm. Da fällt es schwer auf etwas anderes zu wechseln, selbst wenn dort eine API geboten wird.
Schlimmer finde ich die Programme, die zwar eine API anbieten, aber eben keine vernünftige FiBu und dann auch noch zu Preisen, die ich für die gebotene Leistung nicht für angemessen halte.
Übergangslösungen sind ja oft jene, die am längsten genutzt werden.
Dass die API ausgerechnet bei Taxpool vermisst wird kann ich nachvollziehen. Es ist halt ein konkurrenzlos günstiges und doch vollständiges Buchhaltungsprogramm. Da fällt es schwer auf etwas anderes zu wechseln, selbst wenn dort eine API geboten wird.
Gehe ich alles mit.
Und damit keine Missverstaendnisse aufkommen: Ich habe sicher nicht die Erwartung, dass ich fuer den jetzigen Preis das API noch kostenlos dazubekomme. Zumindest mir persoenlich waere das auch einen deutlichen Preisaufschlag wert.
Zumindest mir persoenlich waere das auch einen deutlichen Preisaufschlag wert.
In #20 habe ich schon erahnt, dass sich der "Verbesserungsvorschlag" auf den Preis auswirken könnte. Da ich kein Software-Mensch bin, der aus der API besonderen Nutzen ziehen würde, wie die Entwickler von Schnittstellen, fände ich es sehr schade, wenn sich Taxpool zur Eierlegenden-Wollmilchsau entwickelt und dabei zu teuren Buchhaltungslösungen "aufschließt".
Ich und meine Mandanten benutzen Taxpool gemäß seiner Benennung "Taxpool-Buchhalter". Solange es Erweiterungen gibt, die kostenlos zur Verfügung gestellt werden - siehe z. B. das DMS - ist mir egal, ob ich und/oder meine Mandanten diese nutzen. Wenn aber die API für einen "deutlichen" Preisaufschlag sorgt, werden etliche meiner Mandanten das nicht mit bezahlen wollen.
Vielleicht sollte es dann neben den bestehenden Versionen einfach eine vierte Version für Entwickler geben oder ein kostenpflichtiges Modul, aus deren Lizenzgebühren sich die API trägt. ![]()
Vielleicht sollte es dann neben den bestehenden Versionen einfach eine vierte Version für Entwickler geben oder ein kostenpflichtiges Modul, aus deren Lizenzgebühren sich die API trägt.
So war es auch gemeint gewesen. Aber schlussendlich ist es in meiner Wahrnehmung mit hoher Wahrscheinlichkeit eine theoretische Diskussion. Angesichts der "Geburtswehen" mit der Linux-Version sehe ich nicht, wie das bestehende Team so etwas zeitnah (<12 Monate) liefern sollte. Und ja, ich vermute auch, dass es fuer die Mehrheit der Kunden nicht kritisch ist.
Mal sehen, wie sich der Markt insgesamt entwickelt. Auch als nicht-Fanboy bin ich mir sicher, dass KI hier mit Sicherheit fuer grosse Aenderungen sorgen wird. Und selbst ohne KI kann man in der Buchhaltung schon extrem viel automatiseren. Letztlich war das auch der Grund fuer meine Frage. Jetzt habe ich das halt ausserhalb von Taxpool gebaut und schiebe die Daten per DATEV Import rein.
So war es auch gemeint gewesen.
Ich nehme an, dass sich Deine Einstellung dazu doch nicht geändert hat. ![]()
Vielleicht sollten wir unter dem Verbesserungsvorschlag nun nicht weiter persönliche Gründe des Für und Wider aufzählen und vertriebspolitische Argumente aufzählen. Das führt nur dazu, dass der Kern des Gedanken "Verbesserungsvorschlag" in inzwischen zwei Seiten untergeht. Dass Modular in #21 nochmals auf ODBC eingeht obwohl dies schon seit 2022 - wenn ich es richtig verstehe - nicht umgesetzt werden wird und eine API in Aussicht steht (siehe #4) kann daran liegen, dass
Ist es möglich auf die Taxpool-Daten per ODBC zuzugreifen? (siehe #4)
kann daran liegen, dass nicht mehr alle Beiträge vollständig durchgelesen werden wenn sie so lang werden.
modular Vielleicht sollte die Überschrift passend zu "... API ..." geändert werden, damit Programmierer den Wunsch nicht schon wegen des nicht geplanten ODBC übergehen.
Die REST-API und andere Erweiterungen wie KI-Scan von Belegen sind durch die Arbeiten an der Linuxversion und der Windowsversion mit neuer Oberfläche, die beide mit dem gleichen Entwicklertool erstellt werden, blockiert.
Würden diese mit der alten Entwicklungsumgebung erstellt werden, müssten diese später nochmal für die neue Entwicklungsumgebung konvertiert werden.
Don’t have an account yet? Register yourself now and be a part of our community!