Zuordnung "Beleg zu Buchungssatz": Effiziente Prüfung

Mir ist bewusst, dass aktuell viele Ressourcen in die umfangreiche GUI-Überarbeitung fließen und die hier vorgestellten Ideen sicherlich nicht "mal eben" umzusetzen sind. Dennoch möchte ich diese Gedanken im Forum teilen, damit sie dokumentiert sind und vielleicht zu einem späteren Zeitpunkt als Anregung dienen können.

Hintergrund & Anforderung

Die Prüfung der korrekten Zuordnung von Belegen zu Buchungssätzen dient der Qualitätssicherung in der Buchhaltung - unabhängig davon, ob die Belege weitergegeben werden oder nicht. Eine effiziente Prüfmöglichkeit kann Fehlzuordnungen minimieren und die Zuverlässigkeit und Konsistenz der Buchhaltungsdaten erhöhen.

In meinem konkreten Anwendungsfall geht es um eine Vorab-Prüfung bzw. eine Plausibilitätskontrolle vor der Weitergabe der Buchungsdaten per DATEV-Export an den Steuerberater. Ich möchte dabei prüfen, ob meine Belege (PDF-Dokumente) korrekt mit den Buchungssätzen verknüpft sind. Dies umfasst:

1. Vollständigkeitsprüfung: Sind allen relevanten Buchungssätzen (für die Belege erwartet werden) die entsprechenden Dokumente zugeordnet?
2. Konsistenzprüfung: Stimmt die Zuordnung zwischen Belegen und Buchungssätzen inhaltlich überein?

Die Vollständigkeitsprüfung ist seit Version 19.09 (siehe hier) nach meinem Dafürhalten bereits effizient möglich: Durch Umsortierung der Buchungsliste und anschließende Sichtprüfung lässt sich leicht erkennen, ob das Dokument-Icon (in der ersten Spalte) bei jedem relevanten Buchungssatz erscheint.

Die Konsistenzprüfung hingegen stellt nach wie vor eine Herausforderung dar, da es keine effiziente Möglichkeit gibt, die Zuordnung zwischen Beleg und Buchungssatz zu überprüfen.

Ich verwende eine systematische Benennung meiner Belegdateien nach folgendem Schema:

YYYY-MM-DD-Aussteller-Zusatzinformationen.pdf

Dabei ist der Aussteller je nach Belegart der Lieferant, Dienstleister oder bei selbst erstellten Dokumenten (wie beispielsweise Ausgangsrechnungen, Gutschriften etc.) der eigene Firmenname.

Beispiele

2024-01-16-R+V-Allgemeine-Versicherung-AG-Beitragsrechnung-2024.pdf

2024-01-18-Telekom Deutschland GmbH-2024-01-Rechnung_555999666.pdf

Diese Benennung ermöglicht bereits eine (erste) Plausibilitätsprüfung der Zuordnung zwischen Buchungssatz und Beleg anhand des Dateinamens.

Stand jetzt habe ich leider keine Möglichkeit gefunden, in einer Liste oder Berichtsform zu den Buchungssätzen die jeweils verknüpften Dateinamen auszugeben. Leider erschwert dies einen effizienten Vergleich zwischen den Buchungssätzen und den zugeordneten Belegen.

Anregungen für Lösungen

Kurzfristige Verbesserung

In einem früheren Beitrag hatte ich bereits die Idee eines Tooltip-Features erwähnt:

Beim Überfahren des Beleg-Icons eines Buchungssatzes (in der ersten Spalte der Buchungsliste) könnten per Tooltip die Dateinamen angezeigt werden, die mit diesem Buchungssatz verknüpft sind. So würde durch bloßes Überfahren des Icons mit der Maus eine direkte Prüfung ermöglicht, ob die verknüpften Dokumente vom Dateinamen her zum jeweiligen Buchungssatz passen.

Die Umsetzung dieses Features könnte bereits einen praktischen ersten Schritt darstellen, um verknüpfte Dateinamen und Buchungssätze effizienter zu vergleichen als mit der derzeit einzigen Möglichkeit (Doppelklick auf jeden Buchungssatz, Menü "Dokumente" öffnen und dort die verknüpften Dokumente einsehen). Offensichtliche Fehlzuordnungen könnten so wesentlich schneller erkannt und sodann bereinigt werden.

Übersichtsbericht für Belegprüfung

Als umfassendere Lösung käme eventuell ein Bericht in Frage, der:

• Alle Buchungssätze bzw. solche mit verknüpftem Beleg auflistet
• Idealerweise nach Buchungskonto aufgeteilt ist
• Pro Buchungssatz die verknüpften Dateinamen anzeigt (in den meisten Fällen wird dies nur ein Beleg sein, dennoch sollten immer alle verknüpften Dateinamen aufgelistet werden und nicht etwa nur der erste oder gar ein zufälliger)

Mit dieser Darstellung wäre es einem Anwender möglich, per Sichtprüfung schnell zu erfassen, ob eine Datei falsch zugeordnet wurde (z.B. eine Telekom-Rechnung zu einem buchhalterischen Vorgang, der nichts mit der Telekom zu tun hat).

Nach meinem Kenntnisstand bietet Taxpool aktuell keine Methode zur Ausgabe eines entsprechenden Berichts bzw. überhaupt eines Berichts, der die konkret zugeordneten Dateinamen ausgibt.

Erweiterte Ideen: Präventive Maßnahmen

Neben dem Prüfbericht wären auch präventive Funktionen denkbar und hilfreich:

1. Dateinamenmuster-Definition
   
   • Hinterlegung eines Pattern/Musters für den Dateinamen pro Buchungskonto
   • Möglichkeit regulärer Ausdrücke (Pattern)
2. Automatische Prüfung bei Belegzuordnung
   
   • Automatische Prüfung bei Verknüpfung eines Belegs gegen das Pattern
   • Ablehnung/Sperre bei Drag&Drop, wenn ein Beleg nicht dem erwarteten Muster entspricht
3. Übersteuerbarkeit für Ausnahmefälle
   • Bei Drag & Drop: Übergehung der Prüfung durch gleichzeitiges Drücken einer Zusatztaste (z.B. Strg, Alt oder Shift)
   • Im "Dokument hinzufügen"-Dialog: Checkbox zur Bestätigung oder Nachfrage bei Abweichung des Dateinamens vom definierten Dateinamens-Pattern

Nutzen

Diese Funktionen würden:

• Zeit bei der manuellen Prüfung sparen
• Die Konsistenz der Buchhaltung erhöhen
• Fehler vor der Übergabe an den Steuerberater reduzieren
• Besonders bei größeren Belegmengen die Übersichtlichkeit für die (technische oder zumindest visuelle) Konsistenzprüfung verbessern bzw. überhaupt erst sinnvoll ermöglichen

Zusätzliche Möglichkeiten bei E-Rechnungen

Ich habe mich mit den technischen Details von E-Rechnungen (ZUGFeRD, XRechnung) bisher nicht befasst, aber möglicherweise bieten diese strukturierten Formate zusätzliche Möglichkeiten für automatisierte Prüfungen, die über die hier vorgeschlagenen Funktionen hinausgehen können. Beispielsweise Prüfung der Belegzuordnung anhand der UStID zum Kreditor anstatt des Dateinamens.

Beste Grüsse!

Hi Chris, Danke für die Rückmeldung. Aber ich vermute, dass es da ein Mißverständnis bzgl. dem Thema + Bedarf gab.

Hallo Taxoloop,

vielen Dank für Deine Mühe und die ausführliche Darlegung der Überlegungen und der Rückfragen.

Vollständigkeitsprüfung: Ja, wie geschildert ist das - zumindest für meine Belange - mit den Icons nun hinreichend für eine effiziente Prüfmöglichkeit gelöst. Ob bei einem größerem Buchungsvolumen weitere technische Hilfsmittel sinnvoll sein könnten, möchte ich nicht ausschließen.

Zur Konsistenzprüfung:

Ich schrieb ja bereits "Diese Benennung ermöglicht bereits eine (erste) Plausibilitätsprüfung der Zuordnung zwischen Buchungssatz und Beleg anhand des Dateinamens.".

Das reicht zumindest mir vollkommen. Wie weiter dargelegt würde mich von daher interessieren, ob ich beispielsweise beim Kreditorenkonto "Deutsche Telekom" Buchungen finde, bei denen der Dateinamen beispielsweise "Amazon" enthält.
Aus meiner Sicht wäre für eine manuelle Prüfung am hilfreichsten schlicht ein Bericht, in dem ich das mit dem eigenen Auge - also visuell - schnell überfliegen kann. "Sichtprüfung" habe ich ja extra genannt.
Danach kann man einen so gefunden Beleg (hier also etwa "Amazon" auf dem Kreditorenkonto "Deutsche Telekom") manuell prüfen. Entweder es ist wirklich von Amazon und damit falsch zugeordnet oder aber der Dateiname wurde falsch vergeben. Jedenfalls hat man die Stelle leicht identifizieren können, um eine Prüfung durchzuführen.

Die Notwendigkeit der Prüfung von Datum oder aber Betrag benötige ich nicht.

Technisch unterstützt - also weiter verbessert - wäre denkbar, dass man valide Dateinamen-Pattern direkt auf einem Buchungskonto hinterlegen kann (primär Debitoren-/Kreditoren).
Verknüpft man entweder per "Dokument hinzufügen" oder aber Drag&Drop einen Beleg zu einem Buchungssatz, könnte auf diese Art technisch der Dateinamen gegen das hinterlegte Pattern geprüft werden.

Du führst ergänzend noch diverse Überlegungen und Fragen aus, die ausserhalb der Sphäre von Taxpool liegen und daher irrelevant sind.
Denn: Ob es bei der Vergabe des Dateinamens zu einem Fehler ausserhalb von Taxpool kam, spielt keine Rolle. Das kann und soll Taxpool ja auch gar nicht beurteilen oder kontrollieren.
Wenn der Dateiname falsch vergeben wurde, ist das eben so. Das ist/war aber nichts, wobei Taxpool involviert war bzw ist, da es ausserhalb der Software stattfand.

Und ob der Dateiname ausserhalb von Taxpool manuell vergeben wurde oder aber automatisiert durch bspw. a) einen automatischen Abruf bei den Kreditoren, b) durch einen Extrakt aus E-Mails und anhand von diversen Merkmalen (Absender-E-Mailadresse, PDF Inhalt, PDF Metadaten etc.) oder c) eine ganz andere Zuführungsmethode, spielt gar keine Rolle.

Quote

Auch für eine nur "erste" Plausibilitätsprüfung der Zuordnung zwischen Buchungssatz und Beleg ist der Dateiname m. E. nicht geeignet.

Diese Schlussfolgerung erschließt sich mir nicht, denn hierbei werden Prozessverantwortlichkeiten/-zuständigkeiten in der IT vermischt.
Es ist an dieser Stelle nicht Aufgabe von Taxpool, die externe Vorarbeit zu "challengen", solange es dazu technisch keine Möglichkeit hat.

Und: Das Thema "E-Rechnungen" ist ein ganz separates. Die Belege werde weltweit übermorgen nicht alle samt als E-Rechnung vorliegen. Diese bieten aber sicherlich ganz andere/zusätzliche Chancen für technische Prüfungen. Steht ja auch so im Originalposting unten.

Kurz und knapp:
Ich möchte fehlerhafte Belegzuordnung / Verknüpfungsfehler identifizieren können über die Massendaten hinweg. Mein Anliegen ist nicht herauszufinden, ob der Dateiname korrekt vergeben wurde.

Beste Grüße!
blinky

Hallo wiko-services.de,

Danke auch Dir für Deine Mühe der Rückmeldung

Zu Deinen Fragen:

Quote

wie es zu den Dateinamen kommt. Von Hand vergeben oder wie wird der Dateiname gebildet, bevor die Datei als Beleg verknüpft wird.

Wie es zu dem Dateinamen kommt, ist für Taxpool völlig irrelevant. Für das komplette End-to-End Verständnis mag es sinnvoll sein, aber das wird bei jedem Anwender völlig individuell sein.
Es ist ja nicht die Aufgabe von Taxpool, den Dateinamen zu erzeugen, sondern es wird eine Datei mit einem bestehenden Dateinamen importiert.
Möglichkeiten, wie der Dateiname entstanden sein könnte, habe ich im Posting zuvor erwähnt. Möglicherweise manuell, möglicherweise automatisiert.

Quote

ob die Datei lediglich verknüpft wird oder die Datei auch nach Taxpool kopiert wird und wenn ja, wie dabei der Dateiname gebildet wird

Mein Szenario geht davon aus, dass ein Beleg entweder a) per Drag&Drop oder b) über "Dokument hinzufügen" verknüpft wird. Ob dabei nun das DMS genutzt wird oder nicht, spielt dabei keine Rolle.

Über ausführliche weitere Ideen zum DMS mit MD5 Prüfsummen, Dublettenerkennung und -vermeidung, Kontrolle, ob jeder buchungsrelevante DMS-Beleg einer Buchung zugeordnet ist, wie automatisch Rumpfbuchungssätze anhand der importieren Dateien (stützend auf die Patternerkennung) erfolgen können, lasse ich mich gegenwärtig noch gar nicht aus. Da hab ich noch diverse Ideen seit Monaten, habe aber die weiteren Vorschläge zurückgehalten, da modular mit Verweis auf die Arbeiten an der Linux-Version darum gebeten hatte, keine weiteren Vorschläge einzureichen.

Hinterlegung Pattern je Buchungskonto
Sind Szenarien denkbar, bei denen beide Buchungskonten ein Pattern hinterlegt haben? Vielleicht. Mein Verwendungszweck wären erstmal nur Debitoren- und Kreditorenkonten gewesen. Die Frage ist bestimmt valide und ich vermute, Du hast hier mehr Erfahrung aus der Praxis. Insofern gut, dass es hier eine Austauschmöglichkeit gibt

Das könnte man sicher auch behandeln, indem ein Popup mit einem Hinweis und zur Übersteuerung erscheint (sowieso wünschenswert) und/oder Taxpool ermöglicht, zwei Pattern je Konto zu definieren. Ein Pattern für das Szenario, dass das Konto im Soll bebucht wird, ein zweites Pattern für das Szenario der Bebuchung im Haben. Bei Konten, bei denen es kein Muster gibt, hinterlegt man schlicht kein Prüfpattern.

Quote

Beides geht wohl davon aus, dass der Dateiname vor dem Verknüpfen nicht einer systematischen (ggf. manuellen) Vergabe unterzogen wurde. Hier sollte eine Dateinamensprüfung bei der externen Namensvergabe erfolgen, die dann auch dem gewünschten Muster entspricht.

Nein, beides kümmert sich erneut rein gar nicht darum, was ausserhalb von Taxpool passiert ist. Es ist auch nicht relevant für Taxpool.
Taxpool kann bei Nutzung der Programmfunktionen Prüfungen durchführen, es hat nicht die Vorarbeit in Frage zu stellen. Das Endresultat ist natürlich immer nur so gut, wie die gesamte Prozesskette:

Ist vorgelagert die Dateinamensvergabe 100% korrekt sichergestellt? Und dann auch in Taxpool die Verknüpfung validiert? Perfekt!

Aber: Geschieht vorgelagert ein Fehler bei der Dateinamensvergabe und wird eine solche Datei dann in Taxpool falsch verknüpft, dann mag das vorkommen. Logischerweise ist der Gesamtprozess dann nicht 100%ig sicher, aber qualitativ immer noch besser, als ohne Prüfung.

Quote

Ich würde insgesamt die externe Dateinamensvergabe nicht in Taxpool prüfen, sondern in dem (externen) Prozess. Dort kann die Prüfung und Korrektur gewiss viel gezielter erfolgen. Überdies sehe ich den (geänderten) Dateinamen als untauglich um darin Buchungs- und/oder Belegdaten zu hinterlegen, die dann zu einer Prüfung der Buchung führen sollen.

Ganz genau Denn nur so macht das Sinn in IT. Jedes Modul in einer Kette hat seine Verantwortlichkeiten. Das jeweils nächste System prüft jeweils nur das auf Validität, basierend auf (maximal) dem, was für das jeweilige System prüfbar ist. Dabei helfen End-to-End Sichtweisen natürlich. Hat man den ganzen Datenfluss unter Kontrolle (denke an Eigenentwicklung diverse Module/Anwendungen, die Daten austauschen), hilft es natürlich, wenn man schon Checksummen, "Datei-Ende"-Markierungen etc. konzeptionell vorsieht respektive spezifiziert. Das ermöglicht dem Folgesystem, Prüfungen durchzuführen.

Quote

Es bietet sich an, erprobte buchhalterische Prüfungen* zu nutzen um mögliche Fehler zu finden statt an der fragwürdigen Plausibilität des Dateinamens etwas ablesen zu wollen, was nur indirekten Zusammenhang zur Buchung hat.

"In meinem konkreten Anwendungsfall geht es um eine Vorab-Prüfung bzw. eine Plausibilitätskontrolle vor der Weitergabe der Buchungsdaten per DATEV-Export an den Steuerberater. Ich möchte dabei prüfen, ob meine Belege (PDF-Dokumente) korrekt mit den Buchungssätzen verknüpft sind." So schrieb ich das ja eingangs.

Ich möchte am Jahresende nicht alle Buchungen manuell durchgehen und öffnen müssen, sondern unterstützend ein Instrument haben/nutzen können, dass mich bei der Qualitätssicherung der Massendaten (der Buchungssätze) vor der Weitergabe unterstützt. Stand heute bin ich mit Blick auf die Dokumente allerdings leider "blind", da ich nicht anzeigen lassen kann und daher nicht prüfen kann, welche Belege bei den Buchungssätzen verknüpft/hinterlegt sind und somit nicht sehen kann, was ich exportiere und weiterleiten werde.

Beste Grüsse!
blinky

Die Diskussion mit der API unter jedes Thema zu setzen mag zu Demonstrationszwecken toll sein, aber ist auch wenig hilfreich betreffend der Übersichtlichkeit. Denn es lenkt immer vom Hauptthema ab.

Logisch will man als Entwickler, dass es möglich ist die Software von Aussen kontrollieren zu können, um mehr selbst zu erledigen und weniger von den Entwicklungszyklen bzw. der Herstellerbereitschaft abhängig zu sein, etwaige Features einzubinden. Das ist irgendwie nachvollziehbar, keine Frage.

Eventuell tut es aber dafür einfach ein eigenes Hauptthema dazu?

Wie der Hersteller die Software "schneiden" will, ist im Endeffekt natürlich ihm überlassen. Man muss dabei auch bedenken, dass so etwas organisch gewachsen ist und daher nicht immer perfekt ist. Diverse nativen Drittanbieter-Schnittstellen würde ich persönlich mittlerweile sicherlich auch modular gestalten, zubuchbar - eben gerne für einen Extrapreis, denn man muss hier anerkennen, dass man wirklich ein gutes Stück Software kriegt für einen sehr fairen Preis. Langjährige User mögen sich dabei aber etwas vor den Kopf gestoßen fühlen.

Und das nicht bspw. jede Drittanbieter-Schnittstelle nativ vom Hersteller angeboten werden muss, ist auch nachvollziehbar. Ggf. könnte man sich so im Verlauf der Zeit gar einem gewissen Ballast entledigen.

Nun aber nochmal zum "Schneiden" der Software. Es gibt eine gewisse Kernfunktionalität. Und diese sollte es auch geben. Und eben gewisse grundlegende Funktionen, die eine Anwendung um die Kernfunktionalität herum einfach out-of-the-box integriert haben sollte, damit man damit auch sinnvoll arbeiten kann. Nun bei jedem einzelnen Thema zu rufen "mit API lösbar" mag technisch richtig sein, aber nicht unbedingt die richtige Balance zwischen externen Tools/Modulen sein und dem, was im originären Hauptmodul (=Taxpool) vorhanden sein sollte. Die Meinungen mögen hier differieren, aber evtl. macht es doch mehr Sinn, dies in dem erwähnten Haupt-Diskussionsthema auszudiskutieren. Und eben nicht vergessen: Es ist nun mal der Hersteller, der die letzte Entscheidung hat, wie er seine Software gestalten respektive anbieten möchte.

Just my 2 cent.

Hi Taxoloop ,

ich verstehe Deine Ausführungen. Aber Du versuchst hier erneut einen Fehler zu lösen, der nach eigener Erklärung bereits ausserhalb von Taxpool stattfindet. Und das ist nicht die Aufgabe und auch nicht die Idee der möglichen Kontrollmöglichkeit zu Qualitätssicherung.

Wenn die Dateien unsauber benamt sind, können Fehler passieren. Aber dann ist das schlicht nichts, was automatisch zu erkennen wäre. Daher ist das auch gar nicht Bestandteil der Anforderung an Taxpool.

Es wird nicht um den Wunder-Knopf mit der Funktion "Prüfe alles und stelle absolut sicher, dass jegliche Zuordnung 100% korrekt ist".

Es geht darum zu erkennen, wo Belege offensichtlich falsch zugeordnet wurden. Zum Beispiel weil durch Abo-Buchungen und/oder den Buchungsassistenten anhand von Importen (Kontoauszüge, andere Importquellen) Buchungssätze prinzipiell schon vollständig erzeugt wurden, so dass nur noch der Beleg zugeordnet werden muss. Aber bei eben dieser anschließenden Belegzuordnung (also dem verknüpfen des PDFs mit dem Buchungssatz) möglicherweise ein Fehler geschehen ist. Die Annahme der Prüffunktion muss hierbei natürlich sein, dass die Dateinamen korrekt sein. Wenn dies nicht der Fall ist, ist klar, dass das Prüfresultat nicht stimmt. Aber das liegt ja dann auch nicht an Taxpool, sondern eben der vorgelagerten Arbeit bzw. Applikation, die schlecht gearbeitet hat. Taxpool muss die Arbeit der vorgelagerten Applikation aber nicht wiederholen, sonst hätte es die Anwendung davor ja erst gar nicht gebraucht.

Nennt sich auch "Separation of Concerns" - die Trennung der Verantwortlichkeiten/Zuständigen von Applikationen.
In der IT ganz normal: Garbage In, Garbage Out. Wobei "Garbage Out" hier auf das Prüfresultat abstellt, wenn "Garbage In" (also ein falscher Dateiname) angedient wurde.

wiko-services.de

Quote from wiko-services.de

Tut mir Leid, wenn ich genau das verstehen wollte.

Sorry - meine Antwort bzw. die Art und Weise der Ausführung war nicht als Vorwurf gemeint. Die Frage an sich ist natürlich legitim.
Ich wollte es nur aus technischer Sicht beschreiben, dass es für die gewünschte Taxpool-Funktion irrelevant ist. Denn es ist etwas, dass ausserhalb der Anwendung stattfindet.

Quote

Stimmt. Dann ist für mich die Prüfung auf Dateinamensbestandteile uninteressant, da ich die Belegzuordnung nicht über den Dateinamen vornehme und auch nicht darüber kontrolliere.

Fair Point. Nicht jeder hat den gleichen Workflow.

Taxoloop

Freut mich, dass wir uns jetzt prinzipiell bzgl. der Anforderung verstehen!

Dennoch glaube ich, es liegt ein Missverständnis vor, wie IT-Systeme normalerweise arbeiten.

Kein System prüft die Vorarbeit anderer Systeme vollumfänglich. Denn sonst müsste es die Arbeit nochmal machen. Es kann höchstens einfache Validierungen durchführen, ob das Dateiformat stimmt, die Datei vollständig ist.

Ich gebe Taxpool Dateien mit bestimmten Namen.
Taxpool soll mir helfen zu prüfen: "Wurde diese Datei auf mit den richtigen Buchungssatz verknüpft?"
Nicht: "Ist der Dateiname überhaupt korrekt?"

Letzteres kann Taxpool technisch gar nicht - dafür müsste es den PDF-Inhalt analysieren, Firmennamen erkennen etc. Das wäre ein riesiges Feature und weit weg von der Kernaufgabe einer Buchhaltungssoftware.

Beispiel 1: Windows Datei-Verschieben
- Du hast einen Ordner "C:\Rechnungen\2024\Telekom"
- Du ziehst versehentlich "Amazon-Rechnung.pdf" dort hinein
- Prüft Windows, ob die Datei wirklich in diesen Ordner gehört? Nein.
- Windows verschiebt sie einfach dorthin, wohin du sie ziehst.
(Visuell würde eine solche Datei in dem Verzeichnis aber sofort ins Auge fallen, wenn Du 100 Dateien mit "Deutsche Telekom" hast und eine heraussticht, weil dort Amazon steht.)

Beispiel 2: Analogie aus der realen Welt
- Ein Brief kommt mit Adressaufkleber "Musterstraße 5"
- Der Postbote wirft es in Briefkasten "Musterstraße 12"
- Kann der Postbote prüfen, ob der Absender die richtige Adresse auf den Aufkleber geschrieben hat? Nein - dafür müsste er den Brief öffnen, den Inhalt verstehen, evtl. über die Situation des Empfängers Bescheid wissen und beurteilen können, ob er der richtige ist. Unmöglich.
- Er kann nur prüfen: "Habe ich es an die Adresse laut Aufkleber zugestellt?"

Das ist überall so. Jedes System arbeitet mit den Daten, die es bekommt, und verarbeitet sie dann entsprechend.

Aktuell habe ich keine Möglichkeit einzusehen, welche Belege bei einem DATEV-Export tatsächlich mitgeschickt werden. Ich kann die Verknüpfungen nicht überblicken. Ich bin "blind". Möchte ich aber nicht. Daher würde ich genau diese fehlende Übersicht ganz gerne haben.

Die Prüfung ist bewusst simpel - aber genau das macht sie auch praktikabel und schnell implementierbar.

Eventuell noch als Ergänzung, falls das Untenstehende nicht offensichtlich sein sollte:

Die Prüfung kann auch hilfreich sein, wenn der Ausstellernamen nicht im Dateinamen vorkommt.
Arbeitet man mit den Original-Dateinamen der Aussteller, werden Ausreißer trotzdem sichtbar, da die Dateinamen ja von den Ausstellern normalerweise ja durchgängig einem bestimmten Muster folgen:

Beispiel

RE000323.pdf
RE000421.pdf
RE000425.pdf
invoice.pdf         <-- sticht klar heraus und man kann prüfen, ob die Zuordnung passt.
RE000525.pdf   

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:

Quote from wiko-services.de

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:

Quote from wiko-services.de

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!