Hallo zusammen,
mit dem nun 20ten Beitrag hier möchte ich für meinen Teil abschließen was die funktionale Diskussion betrifft und ergänzend auf das offenbar grundsätzliche Problem der Diskussion eingehen.
Mein Request war: Dateinamen der verknüpften Belege zu Buchungssätzen anzeigen – für effiziente Kontrolle der Belegzuordnung (vor der Weitergabe nach Extern). Dazu verschiedene Ansätze (Tooltip, Bericht) plus erweiterte Ideen zur präventiven Fehlervermeidung (Pattern-Prüfung bei Verknüpfung).
Dann passierte das hier:
- Grundsatzdiskussion ob Dateinamen überhaupt verlässlich sind
- Infragestellen ob die Prüfung nicht außerhalb von Taxpool erfolgen sollte
- Thread-Hijacking für APIs und E-Rechnungen (obwohl schon klar im Eingangspost abgegrenzt)
- Alternative Lösungen vorschlagen (externe Belegnummer, E-Rechnungen, Belegscan-Feature)
- Falsche Prämissen unterstellen
- Versuchen über Feature-Priorisierung zu entscheiden
Das fühlt sich so an, als würde jemand vorschlagen "Ich möchte die Schriftgröße ändern können" und bekommt als Antwort: "Wenn deine Augen besser wären, bräuchtest du das nicht."
Ja, die Fragen waren vermutlich gut gemeint. Aber statt zu prüfen ob die Anforderung für andere User relevant sein könnte, wurde hinterfragt ob:
- Die Voraussetzungen überhaupt stimmen (sind die Dateinamen korrekt?)
- Taxpool der richtige Ort ist (sollte extern geprüft werden?)
- Es nicht bessere Alternativen gibt (E-Rechnungen, APIs, andere Felder?)
Wie derauchnoch es treffend formuliert hat: Es wurden "Fragen beantwortet, die nicht gestellt waren und hier für die gewünschte Funktion nicht relevant sind".
Ob die Ausgabefunktion für anderen Usern auch helfen würde, wurde nicht geklärt. Stattdessen wurde versucht zu erklären, warum die Möglichkeit einer simple Einsicht in bereits vorhandene Daten grundsätzlich falsch oder unnötig sei.
Zu den "besseren Alternativen":
E-Rechnungen kommen erst noch (EU-Pflicht ab 2025/2026), werden nicht weltweit Standard sein, und Belege sind nicht nur Rechnungen (Verträge, Bescheide, interne Dokumente etc.). Auf absehbare Zeit gibt es einen Mix.
Die Belegscan-Funktion (OCR, automatische Zuordnung, Betragsextraktion) ist ein großes Feature das schon lange angekündigt, aber noch nicht umgesetzt ist – vermutlich weil es aufwändig ist.
Aber würde selbst das alle Probleme lösen? Nein:
- Funktioniert nur bei standardisierten Rechnungen
- Nicht bei allen Belegtypen (Verträge, handschriftliche Belege, Screenshots etc.)
- Erfordert trotzdem manuelle Nachkontrolle
- Löst nicht das Problem der Übersicht: Welche Belege habe ich welchen Buchungen zugeordnet? Denn es wird nicht nur E-Rechnungen geben.
Mein Vorschlag ist eine simple Ausgabefunktion – kein Hexenwerk, sondern Anzeige vorhandener Daten. Das ist keine Konkurrenz zu großen Features, sondern eine pragmatische Ergänzung.
Bei Software-Diskussionen erschwert fehlendes IT-Verständnis die Kommunikation erheblich. Mit Strohmann-Argumenten und Ablenkung von der eigentlichen Anforderung wird versucht, diese zu delegitimieren.
wiko-services.de schreibt:
dass Belege von Hand verknüpft werden und dabei offensichtlich ohne den Dateinamen zu beachten
Die für mich bemerkenswerten Stellen im Zitat hebe ich eher so hervor:
Das eigentliche Problem ist aber, dass Belege von Hand verknüpft werden und dabei offensichtlich ohne den Dateinamen zu beachten falsche Verknüpfungen vorgenommen werden.
Und wie sollen Belege denn sonst zugeordnet werden, wenn nicht "von Hand", also manuell? Klar, bei automatischem Import mit Zuordnung mag das anders sein – aber das ist wohl kaum die exklusive Nutzungsweise von Taxpool. Die meisten User werden Belege per Drag&Drop oder "Dokument hinzufügen" manuell verknüpfen.
Und das Wort "offensichtlich" macht daraus eine falsche Tatsachenbehauptung – obwohl genau das Gegenteil der Fall ist. Natürlich wird der Dateiname beachtet, genau deshalb macht der gewünschte Bericht ja auch Sinn. Wo manuell gearbeitet wird, können aber Fehler passieren. Sonst bräuchte Taxpool ja auch keine Löschen- und Storno-Funktionen.
Dann formuliert wiko-services.de: "Ich kann die Entwickler nur darum bitten, ihre Kapazitäten nicht für solche Aufgaben einzusetzen."
Das mag als "Bitte" formuliert sein, ist aber faktisch der Versuch, über die Priorisierung von Features zu entscheiden – eine Rolle die niemandem von uns zusteht. Nennt sich "Gatekeeping" und ist Sache des Software-Herstellers/der Entwickler.
Wenn jeder versucht, Vorschläge anderer zu blockieren weil sie nicht zum eigenen Workflow passen, wird das Forum unbrauchbar.
Wie es derauchnoch bildlich schön ausdrückte: "Der Wurm muss dem Fisch schmecken, nicht dem Angler."
derauchnoch verstand den Request sofort und bestätigte den Bedarf auch in seinem Szenario. Mein ursprünglicher Post war umfassend und klar formuliert – mit Use Case, konkreten Beispielen, Lösungsansätzen und der Erklärung, dass eine solche Ansicht heute nirgends erstellt werden kann bzw. zumindest Unkenntnis darüber herrscht, wie eine solche Ausgabe erzeugt werden könnte.
Für künftige Diskussionen wäre es eventuell wie folgt hilfreich: Verstehen was gewünscht wird → Prüfen ob es für andere User relevant ist → Konstruktiv ergänzen → Entwickler entscheiden lassen.
Oder gar das Unterforum so zu ändern, dass auf Vorschläge erst gar nicht geantwortet werden kann, solange der Hersteller nicht grundlegende Bereitschaft zur Annahme signalisiert hat, dazu Rückfragen hat oder das Thema aktiv zur Diskussion öffnet.
Aus meiner Sicht ist der Request dokumentiert. Hersteller respektive Entwickler entscheiden.
Meinerseits habe ich mich erschöpfend erklärt und daher war es das meinerseits hierzu auch, solange es Hersteller-seitig keine Rückfragen gibt.
Beste Grüße!
