Deinem Anspruch nach müßte Taxpool deswegen auch zu jeder Bank sagen können, wo der User die entsprechenden Dateien bei seiner Bank abrufen kann.
Nein, nur zu der einen, von der Taxpool selbst die Dateien für eigene Tests verwendet hat.
Bei einer Amazon-Datei kommt dafür nun einmal nur Amazon in Frage. Ich halte die Frage, welche Datei genau sich hier (wenn auch experimentell) importieren lassen soll, durchaus für berechtigt.
wieviel "kleines Geld" es wohl zusätzlich
Entschuldige, die Frage hatte ich tatsächlich übersehen.
Das hängt natürlich vom Umfang ab, und davon, ob ein Entwickler dieselbe Funktion mehreren Taxpool Nutzern anbieten kann, oder exklusiv für dich entwickelt.
Ich kann mir sogar vorstellen, dass es gewisse Dinge kostenlos bzw. im "Tausch" gegen Buchhaltungs-Fachwissen geben wird.
In jedem Fall hättest du aber die Möglichkeit, und Taxpool kann um tausende "Sonderlocken" erweitert werden, während alle, die sie nicht brauchen, ganz geschmeidig weiter bei nur 59 Euro bleiben, denn Taxpool hat keinen erhöhten Implementierungs- und Wartungsaufwand dadurch
Es wird ja auch niemand dazu gezwungen, Erweiterungen zu verwenden, die er gar nicht benötigt.
Geht es denn besser?
Ich denke, es geht immer besser.
Ich denke außerdem, dass eine Erklärung, die den Inhalt des Handbuchs in anderen Worten erläutert stets besser ist, als ein Verweis auf oder ein Zitat des original Textes.
Weiterhin halte ich es grundsätzlich in Foren für einen schlechten Ton, dem Hilfesuchenden zu unterstellen, er habe nicht ausreichend gesucht.
Selbst wenn das gar nicht beabsichtigt war, schwingt so etwas immer mit, wenn man jemandem sagt, sein Beitrag wäre unnötig gewesen... ganz egal, wie nett man das verpackt.
Verweise zur Unterstützung von Antworten sind sinnvoll und richtig, aber sie sollten nie ein "hättest du auch selber finden können... stiel mir nicht meine Zeit" zwischen den Zeilen beinhalten - insbesondere nicht von einem Moderator.
Genau so sehe ich das auch.
Ihr möchtet also tatsächlich 10 verschiedene Linux Distributionen verwenden, jede davon für ein anderes Programm, nur weil (angeblich) die jeweils andere Distribution nicht passt?
Abhängigkeiten hast du in der Windows-Welt übrigens genauso. Und obwohl das eine Programm die visual c Bibliotheken in einer bestimmten Version benötigen, ein anderes vielleicht java und ein drittes .NET funktioniert es am Ende doch alles auf dem gleichen Windows...
Und das wird bei der Linux Version nicht wirklich anders sein. Kann ich mir jedenfalls nicht vorstellen...
Alles das findet sich in der Hilfe und müßte nicht hier im Forum erst erfragt werden. Siehe auch hier.
Und was spricht dagegen, hier trotzdem einen guten Service zu leisten, anstatt den Kunden zurecht zu weisen?
Es gibt durchaus auch andere Möglichkeiten, die Integrität eines Dokuments nachzuweisen. Es ist nicht zwingend notwendig ein DMS dafür zu verwenden.
Es kommt, wie du bereits richtig bemerkt hast, auf das gewünschte Ergebnis an.
In der Praxis hat es sich noch nie als effizient erwiesen, sich einen Prozess von einer Software vorschreiben zu lassen. Es sollte immer eine Abwägung stattfinden, um den Einsatz von Software im richtigen Umfang und an der richtigen Stelle zu ermitteln.
Software kann einem das Leben sehr vereinfachen, wenn sie gut auf die Betriebsabläufe abgestimmt ist, aber sie kann einem auch das Leben unnötig schwer machen.
Ob eine Software "gut" oder "schlecht" ist, kann imho nur unter Einbeziehung des jeweiligen Kontext bewertet werden.
Da die Daten von Amazon bereitgestellt werden sollte man dort auch sagen können, wo sie abgerufen werden können.
Das sollte man aber bei Taxpool auch, wenn bei dem Import auf genau diese Dateien verwiesen wird. Da wird sich der Hersteller ja wohl etwas bei gedacht haben. Auch Taxpool sollte das wissen, denn sie müssen die Dateien ja zur Verfügung gehabt haben, um den Import zu implementieren und dessen korrekte Funktion zu testen.
Ich weiß es leider auch nicht.
Nebenfrage: In welcher Beziehung zu Taxpool steht denn eigentlich dieses Forum? Ich war immer der Meinung, dass es eine offizielle Stelle für Hilfestellung wäre, lese aber häufig auch Verweise auf Rückfragen "direkt beim Hersteller" etc.
würde mir als gewöhnlicher User auch die Taxpool-API nichts bringen
In erster Instanz nicht, aber in der Folge sehr wohl.
Du kannst bei anderen Entwicklern genau die Funktion beauftragen, die du benötigst, ohne für deine "Sonderlocke" Kapazitäten des Taxpool Teams beanspruchen zu müssen.
Wenn Taxpool selbst eine Funktion anbietet, ist das schön, aber es ist an vielen Stellen nicht realistisch.
Du würdest entweder ewig auf deine Funktion warten, oder Taxpool müsste sein Entwicklerteam dezent mal verdreifachen, und jeder, der diese Funktion nicht benötigt, bezahlt sie dann mit.
Wie bereits gesagt entlastet eine API die Taxpool Entwickler an den Stellen, an denen sie wegen anderer Priorität gerade nichts tun können oder wollen, ohne dass Nutzer gefrustet auf die Wartebank geschickt werden müssen.
Wenn Taxpool in seinem Kern nicht so großartig wäre, wäre ich längst weg.
dass eine entsprechende Zuarbeit seitens Taxpool dazu nötig wäre. Ohne diese sind auch anscheinend leicht machbare Anpassungen kaum möglich.
Wenn das tatsächlich so sein sollte, dann macht Taxpool da einen sehr bescheidenen Job.
Entschuldige, dass ich das so gerade heraus sage.
Ich kenne kein anderes Linux Programm, das derart tief mit einer speziellen Distribution verwurzelt wäre.
wiko-services.de Ich glaube (hoffe), deine Sorge ist nicht berechtigt. Es gibt keinen nachvollziehbaren Grund für tiefgehende Änderungen der Benutzerführung wegen der Linux Version. Unabhängig von der Linux Version sind aber natürlich Änderungen wohl möglich (und imho teilweise auch sinnvoll)
Lässt sich denn das "Paperless NGX" auch auf dem selben Windows-Rechner betreiben, auf dem auch die Taxpool-Versionen laufen?
Grundsätzlich schon, aber dafür ist es eigentlich nicht gedacht. Es ist für den Serverbetrieb mit mehreren Benutzern ausgelegt. Mit einer Einzelplatzinstallation wird man wahrscheinlich nicht glücklich
Danke für den Test.
Das ist sehr hilfreich und sollte dann ggf. auch in der Doku so vermerkt werden.
Auch dieses Problem ließe sich über eine (lange gewünschte aber immernoch fehlende) API seitens Taxpool lösen und sogar vollständig automatisieren, wenn die Dateien tatsächlich einer definierten Namenskonvention folgen.
Ich bin mir dessen bewusst, dass der normale Anwender in einer reinen API erst mal keinen Mehrwert sieht, aber wenn vorhanden und dokumentiert kann dir jeser einigermaßen erfahrene Entwickler in kürzester Zeit genau deine gewünschte Funktionalität als externe Erweiterung dazu entwickeln, ohne die Taxpool Entwickler zu belasten.
Ich bin überzeugt davon, dass sich in kürzester Zeit solche Anbieter präsentieren würden (ich gehöre auch dazu) und sich ggf. sogar eine Marktplatz-Kultur dazu entwickeln würde, wie es z.B. beim Wordpress CMS schon lange der Fall ist.
Es wäre eine Win-Win-Win Situation für alle beteiligten Parteien.
Taxpool steigert seinen Bekanntheitsgrad exponentiell und kann sich auf die Entwicklung von Kernfunktionen der Buchhaltung und Berichterstattung beschränken (keine Drittanbieter APIs außer die der Finanzbehörden, keine Fragen des Geschmacks beim Formulareditor, keine umfassende WaWi, keine Spezialberichte... das geht dann alles extern in schneller und besser)
Der Nutzer kann die von Ihm gewünschte Funktion in sehr kurzer Zeit erhalten
Softwareentwickler erhalten mit der Taxpool Nutzergemeinschaft neue und wahrscheinlich treue Kunden
Ich bin GEGEN die Integration spezifischer Drittanbieter APIs, jedenfalls so lange, wie noch keine allgemeine umfassende Taxpool API vorhanden ist.
Eine einzige definierte und dokumentierte Schnittstelle seitens Taxpool würde die Integration von Amazon, aber auch gleichzeitig von jedem anderen online Marktplatz (der eine API exponiert) ermöglichen.
Für den Anwender ermöglicht das maximale Flexibilität und für den Entwickler minimale Wartung, da er sich nur auf genau eine API beschränken kann, dier er auch noch selbst definiert hat.
Amazon hat ein API Update? Egal! , denn die Anpassung liegt außerhalb von Taxpool.
ebay hat ein Update? oder WooCommerce? oder PayPal? oder Shopify? oder Hood.de ? oder Esty oder oder oder...
Es ist egal, denn Taxpool kann sich zurücklehnen und sagen "not my circus, not my monkeys"...
Und es wird mit Sicherheit in Null Komma nix von irgendeinem Anbieter eine Taxpool <-> Amazon Bridge dann geben, der sich nur darum kümmert (und kleines Geld damit verdient... sei ihm gegönnt... wer dafür nicht zahlen möchte, könnte ja auch selbst entwickeln, wenn die jeweilige API beider Seiten bekannt ist)
Taxpool in der Linux-Version wird NICHT unter Debian laufen?
Doch, wird es, sofern von Taxpool Seite die Abhängigkeiten klar kommuniziert werden, und du diese in der richtigen Version nachinstallierst.
Es wird eben nur nicht ohne zusätzlich zu installierende Abhängigkeiten auf debian Distributionen laufen.
Wenn es tatsächlich "nur" um Qt und die entsprechenden c Bibliotheken geht, dürfte das sogar relativ leicht machbar sein.
Das DMS von Taxpool ist imho ziemlich ... na, sagen wir mal "klassisch" gehalten 
Einen Pluspunkt gibt es aber für die Möglichkeit, einen Zeitstempelserver zu verwenden. Die Zeitstempelserver von den üblichen Zertifikat-Stellen werden allgemein auch als vertrauenswürdiger Nachweis der Integriät (Unverändertheit... sagt man das so?) akzeptiert.
Andere DMS, die sich auf bequeme Dokumenentenablage spezialisiert haben, stecken das Taxpool DMS bequem in die Tasche, lassen aber häufig genau diesen Nachweis außer Acht (oder sind sau teuer).
Wenn man sich auskennt, ist wahrscheinlich ein Workflow
Erst stempeln -> dann im DMS (z.B. Paperless NGX) einchecken -> dann mit Belegnummer "taggen"
realisierbar, wobei der letzte Schritt (Belegnummer zuordnen) mangels Taxpool API noch von Hand erfolgen muss.
Muss er aber auch, wenn man gar kein DMS verwendet
Ich kann mich nicht erinnern, in irgendeinem Gesetz oder irgendeiner Norm eine Vorschrift zur Platzierung von QR Codes auf Rechnungen gelesen zu haben.
Und nein, rein technisch betrachtet hätte ein Vorlageneditor so rein gar keine Grenzen, außer die, die vom Entwickler gesteckt werden.
Ich habe die Aufteilung sehr wohl verstanden (es wird ja auch oft genug von euch darauf hingewiesen)
Ich hatte allerdings gar keinen Verbesserungsvorschlag im Sinn, sondern habe lediglich auf einen Beitrag geantwortet. Ob es nun der erste oder vierte Beitrag im Thread war, ist doch völlig unerheblich.
Ich verstehe nicht, warum sich compliance und usability gegenseitig ausschließen müssen.
Im Gegenteil fördert eine gute intuitive Benutzbarkeit sogar die Einhaltung der Richtlinien, denn eine Software kann ja pauschal nicht von sich aus eine Norm einhalten. Die Norm gilt für das, was der Anwender damit tut.
Ich nutze Taxpool tatsächlich auch nach so langer Zeit nur deswegen, weil die Buchhaltungsfunktionen hervorragend sind und das zu einem vernünftigen Preis.
Ich verstehe auch, dass hier der Fokus liegt, und alles andere mehr oder weniger "Beiwerk" ist.
Ich würde mir ja nur wünschen, dass ihr einfach mal ehrlich damit umgeht, und ggf. sogar Dinge lieber gar nicht anstatt halbherzig implementiert.
Eine ordentliche Programmierschnittstelle z.B. würde all dies lösen, denn dann könnte die visuelle Erzeugung der Rechnung ganz bequem extern erledigt werden, von jemandem, der vielleicht weniger von Buchhaltung aber sehr viel mehr von Vorlageneditoren versteht, und ihr hättet jede Menge Zeit gespart.
Ich würde mich unendlich gerne an der Entwicklung von Erweiterungen für Taxpool beteiligen, aber leider geht das (noch) nicht.
Ich wünsche mir als Nutzer mehr Lösung und weniger Rechtfertigung.
Taxoloop es ist bedauerlich, dass du den Zweck des Beitrags nicht verstanden hast.
Aus dem Eingangspost war ganz klar erkennbar, dass der Fragesteller den Girocode in einem Objekt "Fußzeile" platzieren wollte.
Ich hätte wohl auch einfach schreiben können "geht nicht", hielt aber eine ausführlichere Ausführung für hilfreicher.
Der beschriebene Fehler erlaubt hier zumindest - wenn auch so nicht vorgesehen - etwas mehr Gestaltungsfreiraum bei der Platzierung des QR Code, zumindest so lange, bis der zu Grunde liegende Programmfehler behoben wird.
PS:
Ich habe leider - so auch hier - häufig den Eindruck, dass ihr vor Lauter Buchhalterdenke den Fokus aufs Wesentliche verliert. Das hier ist ein Forum, und keine Aktenablage. Auch hat in ein "wie vorgesehen [..] erscheint" wenig mit Nutzerfreundlichkeit zu tun. Wenn ein bestimmtes Layout "vorgesehen" ist, dann braucht man keinen Vorlageneditor.
Ca. im Oktober.
Da sich der Oktober nun dem Ende zuneigt, wollte ich nochmal um ein Update zum aktuellen Entwicklungsstand bitten.
Moin!
Mit Taxpool wird immernoch die libpg DLL in der Version 13.0.17 mit ausgeliefert, und auch die Hilfe empfiehlt, Version 13 von PostgresSQL zu verwenden.
Postgres 13 wird das finale Release voraussichtlich am 13. November dieses Jahres (2025) erhalten und danach nicht mehr weiter entwickelt.
Daher sollte Taxpool spätestens zu jenem Zeitpunkt auch neuere Versionen von Postgres unterstützen.
Die aktuelle Stable Version von Postgres ist inzwischen bereits 17.5 und 18 ist als Beta verfügbar.
Tatsächlich funktionieren der GiroCode als auch die Girocode-Box wohl nur in einem Objekt vom Type "Hauptteil".
Das schränkt die Gestaltung stark ein, weil der Hauptteil üblicherweise die gesamte Breite einnimmt, und wenig Spielraum für eine freie Platzierung der verschiedenen Inhalte lässt.
Dazu kommt, dass bei der Box keine Formatierungs-Tags im Girocode-Text verwendet werden können.
Die Anwendung Quittiert den Versuch mit einem kritischen Java-Fehler fo.inline is not a child of fo.table.
Wenn man die Formatierung (z.B. kleinere Schrift oder Farbe) außerhalb der Girocode-Box setzt, so gelten diese entsprechend für den gesamten Text. Zum Beispiel ist eine Kleinere Schrift ab Zeile 2 so unmöglich bei Verwendung der Girocode-Box.
Sich eine eigene Box zusammenzubauen, scheidet ebenfalls durch die Beschränkung auf den "Hauptteil" aus. Sonst könnte man ja mit Hilfe des Nur-Code Elements etwas basteln.
Durch Ausnutzung eines weiteren Fehlers kann man allerdings etwas Tricksen.
Die Girocode-Box verschiebt die aktuelle Y-Position im Dokument NICHT, wenn man um die Box herum zwei verschachtelte Formatierungsanweisungen gesetzt hatte, wie z.B. <small><color="black"> hier der Boxcode </small></color>
Ein Text, der nach der Box noch kommt, überlagert dann die Box anstatt sich darunter zu setzen.
Auf diese Weise ist es möglich, einfach eine Box mit "leerem" eigenem Text zu erzeugen, un dann den tatsächlich gewünschten Text (fehlerhafterweise) darüber zu legen.
Das ist keineswegs eine dauerhafte Lösung und wird in dem Moment auch das Layout zerstören, wenn hier der eigentliche Bug gefixt werden würde.
Ganz allgemein ist das mit dem QR Code ja ganz nett gemeint, aber leider so ziemlich halbgar.
Auch für entsprechende Lokalisierung des Box-Textes muss man einen ganz schönen Umweg beschreiten, der aber wie dokumentiert funktioniert und deshalb völlig in Ordnung ist.
