Posts by blinky

Hallo wiko-services.de ,

Danke für den Hinweis bzgl. dem ersten Link. Der war tatsächlich nicht funktional - habe ich soeben korrigiert.

Ansonsten folgte die beschrieben Struktur folgte der, die die Website vorgibt:

Das auf der "Download-Seite" (wie im Screenshot ersichtlich) primär eine Beschreibung mit weiteren Links vorkommen - mittlerweile ergänzt um den letzten Eintrag für Portable - kann ich nicht ändern. Daher auch der Hinweis, dass ein weitere Link zur downloadbaren Datei führt.

Dennoch Danke für die Ergänzung, insbesondere das ZIP-Archiv des Offline-installers.

Hi HK_Taxpool,

es gibt die sogenannte "Portable"-Version - sieh auch die Hilfe-Seite Taxpool FAQ zur "Portable Version".

Auf der Download-Seite der Taxpool-Buchhalter MINI Version gibt es unten den Link auf die Download-Seite.

Dort solltest Du den "Portable" Installer auswählen.

Nachdem Du das Installationsprogramm startest, musst Du die entsprechende Auswahl Mini/Portable tätigen und als Installations-Zielverzeichnis Dein ein Verzeichnis ("Ordner") auf Deinem USB-Stick benennen:

Viel Erfolg!

Vielen Dank für die Ausführungen! Ich habe besser verstanden, worauf Du hinaus möchtest.

Du hast recht, ich implizierte, dass das Feld BU-Schlüssel eine eindeutige Zuordnung hat.

Aber genau das ist auch mein Verständnis der DATEV-Dateistruktur: Das Feld 9 (BU-Schlüssel) ist fest verbunden mit dem Feld 8 (Gegenkonto).

Siehe Format-Beschreibung "Buchungsstapel" und in der Dokumentation Buchungsstapel erfassen die Erläuterung zum (Kombinations-)Feld "BU Gegenkto (Berichtigungs- und Steuerschlüssel / Gegenkonto)". Dort wird das Kombinationsfeld "BU Gegenkto" beschrieben als ein Feld für Gegenkonto und Berichtigungs-/Steuerschlüssel. Es handelt sich um EIN logisches Feld "Gegenkonto mit BU-Schlüssel", das im DTVF-Export in zwei separate Datenfelder aufgeteilt wurde.

Der Vollständigkeit halber hier noch die (unvollständige) Zeile aus der DTVF-Originaldatei:

Eventuell steh ich ja irgendwo "auf dem Schlauch". Die raportierten Datensätze werden nach dem Import in "rot" hervorgehoben. Sehr gut

Sieht dann so aus:

Die Nachfrage bei Selektion und anklicken von "Ändern" ist genau diese hier -- wobei ich es so verstehe, dass die Entscheidung doch aus dem angelieferten Steuerschlüssel ableitbar ist:

Hi Taxoloop, Danke für die Info, insbesondere den Ausschnitt aus dem BMF Schreiben

Ja, ich weiß und wusste vor meinem Post, wo/wie die Vorsteuer zu verbuchen ist. Aber das war nicht meine Frage, denn darum ging es mir ja gar nicht in meinem Posting.

Es scheint mir doch vielmehr so zu sein, dass die für die Entscheidung notwendigen Daten vorliegen. Also ist es auch technisch möglich, die entsprechende Entscheidung anhand dieser importierten Daten vorzunehmen. Dann wäre es doch auch schön, wenn das berücksichtigt und somit "sauber" verarbeitet würde, ohne die Notwendigkeit eines manuellen Eingriffs (Recherche und manueller Entscheid). Somit wäre das Thema wohl im Bereich der Verbesserungsvorschläge besser aufgehoben.

Konkret wurde hier eine Mitgliedsrechnung für einen 12-Monatszeitraum verbucht. Die zugehörige Rechnung wurde am 21.06. ausgestellt und am 30.06. per Lastschrift vom Bankkonto bezahlt.

Seitens der Buchhalter bei der Kanzlei höre ich öfter, dass bei mir "gegen die Bank" gebucht wurde/wird. Wohl aus Vereinfachungsgründen, da die Buchhaltung überschaubar ist.

Daher wurde die Zahlung der Rechnung wohl gegen das Abgrenzungskonto gebucht und dann der Nettobetrag über die folgenden 12 Monate hinweg mit jeweils 15 EUR gegen 6600 (Werbekosten) aufgelöst. Die Vorsteuer gehört ja aber dennoch in den Juni.

Ja - im konkreten Beispiel ist das aus 2014. Habe ja aber auch alle weiteren Buchungen bis und inkl. Anfang 2024. Dein Einblick in die Vergangenheit erachte ich ganz gut, auch zum evtl. nachschauen, wie etwaige Sachverhalte verbucht wurden (insbesondere zum Nachschauen ("spicken"), falls es ähnliche Vorkommnisse in der Zukunft gibt.

Hallo zusammen!

Beim Import einiger DATEV-Buchungsstapel erhalte ich die im Screenshot ersichtliche Meldung "Es kann nicht festgestellt werden, ob die Steuer im Soll oder im Haben gebucht werden soll."

Die Steuerschlüssel scheinen jedoch seitens DATEV eindeutig definiert zu sein (am Beispiel für 2019): Steuerschlüssel-Tabelle für Regelbesteuerung 2019

Dies der Steuerschlüssel, obwohl im PDF-Fehlerreport explizit angezeigt, bei der Verarbeitung der importieren Buchungsdatensätze nicht berücksichtigt?

Oder mangelt es mir hier an dem erforderlichen Verständnis, d.h. dass es nicht so einfach geht, wie ich das vermute?

Besten Dank!

Besten Dank für die Erläuterung! Hatte auch überlegt, einfach mit zwei Mandanten zu arbeiten, um das Ziel zu erreichen.

Nach meinem jetzigen Verständnis benötige ich die Abschlussbuchungen nach steuerrecht zur Entwicklung der SB / E-Bilanz selbst ja gar nicht, da der StB das übernimmt.

Zu den Fragen

Gegenwärtig wurden mir vom Buchhalter die existierenden Buchungen der vergangenen Jahre im DATEV-Format überlassen.

Im Gespräch mit ihm kam der Hinweis auf, dass die überlassenen Dateien auch steuerrechtliche Buchungen enthalten. Das Einlesen beider Stapel führt ggf. nicht zum gewünschten Ergebnis - bzw. es gibt die grundsätzliche Überlegung anzustellen und Entscheidung zu treffen, ob ich die Daten in Taxpool nun handels- oder steuerrechtlich einlesen und erfassen mag.

Für die laufende Buchung sind wir so verblieben, dass ich "ganz normal" nach Handelsrecht buche. Nach Überlassung der Buchhaltungsdaten an den Mitarbeiter Kanzlei des StBs am Jahresende werden dann dort die steuerrechtlich relevanten Buchungen im Rahmen des Jahresabschlussarbeiten durchgeführt werden -- und evtl. auch vorab handelsrechtliche Korrekturen, so sie erforderlich sind.

Die dort durchgeführten Buchungen werden ich als Export wieder zurückerhalten.

Damit die Bilanz und die EB-Werte stimmen, werde ich davon dann wohl zumindest die handelsrechtlichen (Korrektur-)Buchungen wieder einspielen. Die steuerrechtlichen nicht - oder evtl. in einen zweiten Mandanten, wie von Taxoloop vorgeschlagen.

[...]

Ich habe nun einmal die überlassenen DATEV-Exportdateien des Gründungsjahres genauer gesichtet:

• Das technisch relevante Feld zur Unterscheidung lautet "Rechnungslegungszweck" gemäß DATEV-Formatbeschreibung.
• Der Großteil des Dateien hat hier den Wert 0 (unabhängig) -- nach Erläuterung bucht man standardmäßig aber sowieso nach handelsrechtlichen Vorschriften.
• Eine Datei der Abschlussbuchungen hat den Wert 50 (Handelsrecht)
• Eine weitere Datei der Abschlussbuchungen hat den Wert 30 (Steuerrecht)
  • Darin enthalten sind Buchungsdatum 31.12. Buchungssätze (Konto 9970 gegen 9971)

Beigefügt eine Übersicht aller Header für erste Buchungsjahr. Mit Endung für eine Textdatei hochgeladen (unterstützte Dateitypen), ist aber eine CSV. Habe die einige Felder der Datei anonymisiert.

Besten Dank!

Guten Tag!

In einem Abstimmungstelefonat mit einem Mitarbeiter meines Steuerberaters haben wir den Datenaustausch DATEV <-> Taxpool erörtert.

Hierbei ist das Thema der handels- bzw. steuerrechtlichen Verbuchung aufgekommen.

DATEV scheint "sauber" zwischen beidem zu trennen. Mir wurde erklärt, dass es im Prinzip ähnlich wie zwei parallele Buchhaltungen zu verstehen ist.

In meinem Fall werden üblicherweise Rahmen der Abschlussarbeiten die steuerrechtlich relevanten Buchungen durchgeführt.

Es kam nun also die Frage auf, wie in Taxpool damit umgegangen wird bzw. umgegangen werden soll. Mir liegen DATEV-Exportdateien für den Import sowohl handels- als auch steuerrechtlich vor.

Der Mitarbeiter erwähnte, dass ich mich vermutlich für eine "Sicht" entscheiden muss. In der Kopfzeile der DATEV-Datei ist ja immer (kodiert) erkennbar, ob es sich um handels- oder steuerrechtliche Buchungssätze handelt.

Evtl. könnt ihr mir Infos aus der Praxis liefern? Wie handhabt ihr das? Oder kann Taxpool hier auch zwischen beiden "umschalten" ?

Vielen Dank!

Habe keine eigene Erfahrung mit Anlagen-Verbuchung - nur erste Ideen:

Die vollständigen Daten einer Anlage werden verständlicherweise Weise nicht automatisch angelegt werden können. Aber wäre nicht ein Rumpfdatensatz denkbar, der dann entsprechend zu präzisieren ist? Ein solcher Rumpfdatensatz könnte bereits den Wert aus der Buchung erhalten/"erben" und Zugriff auf das mit der Buchung verknüpfte Dokument anbieten.

Bei nicht-selbständigen Wirtschaftsgütern, wie etwa einzelnen PC-Komponenten, stellt sich die Herausforderung, diese später zu einer Gesamtanlage (z. B. PC-Komplettsystem) zusammenzufassen. Eine Funktion, die es erlaubt, solche Einzelkomponenten (Einzelbuchungen/Anlagen) zu bündeln und in einem zweiten Schritt als eine Anlage zu verbuchen, wäre dafür dann sehr hilfreich.

Spannend. Die Felder in diesem Format sehen spontan dem "DATEV-Format" (DTVF/EXTF) sehr ähnlich.

Muss ich mal schauen, ob eine solche Datei denn nach Taxpool importierbar wäre.

Danke!

Hallo Taxoloop ,

vielen Dank für die umfassende Erklärung zu Deiner Rolle und Deinem Selbstverständnis

Eine kurze Anmerkung:

Quote

Schließlich würde ich die Buchungen aus dem Vorsystem in einer Ausspielung pro Jahr vornehmen. Wenn also die Buchhaltung über 10 Jahre eingespielt werden soll - was sicher auch nicht der Regelfall ist - dann sind einmalig 10 Dateien einzuspielen.

Genau selbiges hatte ich auch erwartet, durfte aber vom Buchhalter erfahren, dass er da in DATEV gar keine Kontrolle darüber habe, sondern die dortige Exportfunktionalität eben so gestaltet ist, dass Buchungsstapel-weise exportiert wird. Der "Buchungsstapel" scheint bei der DATEV ein recht zentrales Gliederungselement zu sein (meine jetzige Annahme basierend auf den erhaltenen Erklärungen). Auch wird dann noch zwischen Buchungen nach Handelsrecht und Steuerrecht unterschieden, die im DTVF-Header indiziert werden.

Morgen erfahre ich evtl. etwas mehr mit einem Einblick in die DATEV-Software per Screen Sharing.

Danke + Gruss

blinky

modular

Noch ergänzen möchte ich:

Die Umstellung zu CAMT ist im Gange. Eben im üblichen Banken-IT-Umstellungstempo. Das Ganze läuft unter ISO 20022 und das kommende Jahr 2025 spielt hier bereits eine entsprechende Rolle. Es dürfte nicht allzu lange dauern, bis es final auch bei den Endkunden im Online Banking ankommt.

Beispielhaft

2025 und 2026 -> Commerzbank: ISO 20022 Umstellung Zeitplan

Nov'2025 --> DATEV -> Das Format MT940 wird von der Deutschen Kreditwirtschaft zum November 2025 abgekündigt und durch das Format camt.053 (CAMT-Format) ersetzt.

Zur Info zwecks entsprechender Design-Entscheide in der Entwicklung.

Hallo modular,

vielen Dank für die Informationen!

Quote

Ein Einsatz von LUA vor und nach dem Import ist bereits auf der ToDo-Liste, da aber derzeit viele wichtige Sachen in der Warteschlange stehen, kann das noch lange dauern.

Danke für den Einblick in die ToDo-Liste!

Ich fasse zusammen

- Externer Parser soll durch interne Funktionen ersetzt werden, geplant ca. Anfang 2025.

- Online-Banking Schnittstelle verbessern, evtl. eigene Online-Banking Fähigkeit oder aber unter Nutzung von Hibiscus, evtl. ab Mitte 2025.

- LUA-Skript vor/nach (Kontoumsatz-)Importen ausführen ist ein Eintrag auf der ToDo-Liste, aber niedrig priorisiert. Nicht in der konkreten Planung.

Ich bin neugierig:

Gibt es denn für uns Anwender auch einen Einblick in die Roadmap oder ToDo-Liste? Ggf. inklusive Priorität.

Falls nicht, nicht schlimm. Ist ja auch immer eine Art Commitment und schraubt die Erwartungshaltungen hoch.

Aber eventuell gibt es das ja doch bereits und ich weiß nur nichts davon. Daher frage ich.

Anpassen der Verwendungszwecke

Danke für die Anregung wg. Notepad++ bzw. den CSV-Exporten. Prinzipiell versuche ich es immer, manuelle Schritte möglichst zu vermeiden.

In Hibiscus scheinen die originalen MT940-Daten zu liegen, aber möglicherweise auch bereits "optimierte" Verwendungstexte.

Denn im MT940-Export wird augenscheinlich das Original samt KREF+, EREF+ etc. ausgegeben. In der Hibiscus-GUI wird es aber schöner dargestellt und auch beim CSV-Export "optimiert" ausgegeben.

Es scheint sogar, dass Hibiscus möglicherweise bereits einige Informationen aus dem Verwendungszweck extrahiert.

Der Vollständigkeit halber hier die Ansicht des zweites Beispiel-Umsatzes aus meinem Post oben. Ich musste entsprechend auch im Screenshot die Echtwerte durch Beispielwerte ersetzen, daher die darin ersichtlichen Manipulationen.

Man beachte unten die Umschaltmöglichkeit hin zum Original-Verwendungszweck anstatt des von Hibiscus bereinigten Textes:

Mir fällt hierbei gerade auf, dass Hibiscus die Reihenfolge im Verwendungszweck nicht konsequent ausgibt.

• In der MT940-Datei werden EREF, KREF, MREF am Ende ausgegeben (wie im Beispiel in meinem vorherigen Post und wie von Taxpool nach dem Import auch dargestellt).
• In der Hibiscus-GUI wird es aber anders herum angezeigt (siehe ersten Screenshot, unten).

Ob die Reihenfolge der Elemente (EREF, MREF, CRED, SVWZ etc.) bei MT940 bzw. im SEPA-Kontext streng definiert ist oder flexibel ist, was ich spontan nicht. Ich tippe auf flexibel. Dennoch interessant zu wissen. Es wird spannend, welche Werte Hibiscus in der Datenbank ablegt respektive per RPC zurückgibt.

Danke + Gruss!

blinky

Quote

Ich habe aber noch nicht verstanden, was Du konkret beeinflussen willst.

Ich möchte im Rahmen des MT940 Imports den Text für den Buchungsvorschlag verändern können, so dass beispielsweise die SEPA-Abkürzungen automatisch entfernt werden. Die Logik dürfte durchaus komplexer werden, deshalb die Frage nach einem extern aufrufbaren Tool oder LUA-Skript.

Beispielhaft

Liefert die MT940-Datei beispielsweise (modifizierte Echtdaten)

192/OCMT/EUR525,00//LU00000000012300000BIC:XXXXXABCXXXKREF+NONREF Zahlungseingang

so wäre im einfachsten Fall beispielhaft KREF+NONREF zu entfernen:

192/OCMT/EUR525,00//LU00000000012300000BIC:XXXXXABCXXX Zahlungseingang

Mit einem regulären Ausdruck könnte auch die ISIN und BIC des Absenders erkannt und entfernt werden:

192/OCMT/EUR525,00// Zahlungseingang

Noch ein Beispiel (partiell Echt- durch Beispielwerte ersetzt):

OTHR Sonst. Transakt /INV/88051005 31.8.2024Abrechnungszeitraum: 2024-08-01EREF+0816555555KREF+NONREFMREF+1444100020-003CRED+DE88ZZZ00000123456 Zahlungsausgang

könnte nach simpler Entfernung von OTHR, EREF+, KREF+ , MREF+ CRED+ im Ergebnis beispielsweise so lauten:

Sonst. Transakt /INV/88051005 31.8.2024Abrechnungszeitraum: 2024-08-01 0816555555 NONREF 1444100020-003 DE88ZZZ00000123456 Zahlungsausgang

oder falls gewünscht eine String-Substitution durchgeführt werden:

Sonst. Transakt /INV/88051005 31.8.2024Abrechnungszeitraum: 2024-08-01 ExtRef 0816555555 MRef 1444100020-003 Zahlungsausgang

oder nach "cleverer" Löschung des zum EREF/KREF/MREF/CRED zugehörigen Wertes sowie Löschung des unnötigen Strings "Sonst. Transakt /" :

INV/88051005 31.8.2024Abrechnungszeitraum: 2024-08-01 Zahlungsausgang

Der Vollständigkeit halber sei erwähnt:

Obiges basiert auf Daten der Deutschen Bank, nach Abruf mit Hibiscus und Export als MT940-Datei zwecks Import nach Taxpool. CAMT wäre hier wohl das Mittel der Wahl, da die Daten dort hoffentlich bereits "sauber" sind (meine Hoffnung). Leider habe ich gegenwärtig keine Möglichkeit für einen entsprechenden CAMT-Datenbezug.

Quote

Der Verwendungszweck ist ja von der Bank gegeben, den kannst Du nur in den Buchungstext übernehmen und dort bearbeiten.

Ok - Danke! Das hatte ich vermutet. Meine Hoffnung lag darauf, einen beliebigen externen Parser einbinden zu können, in dem die Ersetzungslogik untergebracht ist. Aber so überlegt muss man eventuell einfach direkt an die MT940-Datei heran und die Modifikationen des Verwendungszweckes dort durchführen.

Besten Dank für die Infos!

Hallo wiko-services.de,

vielen Dank für die Information!

Gerne würde ich verstehen, was Du damit meinst, dass der Verwendungszweck "mit Bordmitteln von Taxpool ausgewertet werden" kann?

Ich möchte ja nichts auswerten. Gibt es eine Suchen+Ersetzen Funktion? Prinzipiell will ich ihn ja textuell verändern.

Oder spielst Du darauf an, dass ein LUA-Skript die aus dem MT940-Dateiimport resultierenden Buchungstexte bearbeiten könnte?

Vielen Dank!

Grüße

blinky

Hallo wiko-services.de,

vielen Dank für deine Antwort und die Zustimmung zum grundsätzlichen Problem! Es freut mich, dass wir da einer Meinung sind.

Allerdings hatte ich den Eindruck, dass vielleicht nicht ganz klar geworden ist, dass der Beleglink sich auf die technische ID bezieht, die im DATEV-Belege-Export schlussendlich auf die übermittelte Datei verweist (üblicherweise ein PDF).

Der "Beleglink" ist also die technische Referenz auf die Datei, die ebenfalls erzeugt (und dann auch zum StB übermittelt) wird, wenn beim DATEV-Export das Häkchen bei "Belege exportieren" gesetzt wird. Solch übermittelte Belegbilder können dann beim Steuerberater/Buchhalter nach DATEV Belege online importiert werden.

Darüber hinaus:

Es ist bei Schnittstellen grundsätzlich eine der großen Herausforderungen, die jeweiligen Besonderheiten der Gegenseite zu berücksichtigen und zu handhaben, insbesondere wenn diese Systeme autonom voneinander entwickelt werden und keine Abstimmung über das Systemverhalten oder die Anforderung an die Schnittstellenspezifikation stattfindet.

Dass sich der Monolith DATEV hier an Taxpool anpasst, ist wohl wenig wahrscheinlich. Daher liegt der Ball schon nahezu zwangsläufig beim kleineren Part - hier also Taxpool -, um im DATEV-Exportmodul eine Lösung zu finden, so dass die Besonderheiten der DATEV-Schnittstelle zielführend berücksichtigt werden. Die von mir genannten Ansätze waren bereits Lösungsmöglichkeiten, um genau diesen Datenverlust zu vermeiden. Meine obige Idee der Nullbuchungen klappt nicht, da wohl gar nicht erlaubt (bzw. so nicht in DATEV möglich). Daher scheidet das als "Transport-Vehikel" (für die Daten der Hauptbuchung samt Beleglink aus.

Dass die verknüpften Belege im aktuellen Prozess sogar stillschweigend verloren gehen können, ist meines Erachtens ein weiterer kleiner Fauxpas, der es wert wäre, behoben zu werden.

Ich denke, es würde allen Nutzern, die die Funktion des Belegübertrags zum StB (also Dokumentenübertrag in das DATEV System) nutzen, sehr helfen, wenn die Belege/Dokumente beim Übertrag nicht unterschlagen/verloren gingen, sondern erhalten blieben.

Natürlich gebe ich dir recht, dass man aktuell mit Workarounds arbeiten kann, um den Verlust bei Splitbuchungen zu verhindern. Allerdings muss man als Anwender das aber auch erstmal wissen. Übergangsweise wäre eventuell schon ein entsprechender Warnhinweis nützlich.

Ich muss selbst noch prüfen, ob in Taxpool Splitbuchungen auch bei Rechnungen möglich sind, im Programmbereich Lieferanten bei einem Kreditor oder aber Debitor zugeordnet sind. Denn auch dort könnte das Problem auftreten.

Viele Grüße,

blinky

Hallo zusammen,

hier nun zu dem eigentlichen Verbesserungsvorschlag - vielen Dank für eure bisherigen Antworten.

1. Direkte Zuordnung per Drag & Drop ohne Vorheriges Auswählen des Buchungssatzes

Mir ist bewusst, dass Fehler bei der Zuordnung von Dokumenten passieren können, wenn man nicht präzise genug arbeitet. Doch das allein sollte meiner Meinung nach nicht bedeuten, dass wir alle Nutzer zu unnötigen Klicks zwingen, nur um sicherzugehen. Immerhin erscheint nach einer erfolgreichen Zuordnung ein Icon links neben dem entsprechenden Buchungssatz, wodurch recht klar ersichtlich ist, welchem Buchungssatz ein Dokument zugeordnet wurde.

Ein Vorschlag, um das Risiko von Fehlzuordnungen zu reduzieren, wäre eine zusätzliche farbliche Hervorhebung des Zieldatensatzes, sobald man mit dem Dokument darüber schwebt. Das würde die visuelle Orientierung verbessern und Fehlzuordnungen verhindern, ohne die Benutzerfreundlichkeit einzuschränken.

Denkbar wäre auch, dass ein „direkter" Drag & Drop Modus eingeführt wird, den der Nutzer selbst im Bedarfsfall auswählen kann. So hätten Anwender, die gerne direkt und effizient (ohne explizite Anwahl des Buchungsdatensatzes) arbeiten wollen, diese Möglichkeit, während Nutzer, die eine sicherere Methode bevorzugen, beim bisherigen Vorgehen bleiben könnten.

2. Effizienz der Arbeitsabläufe und Gewöhnung

Das Aussage, dass ich mich nur noch an die aktuelle Handhabung gewöhnen müsse, betrachte ich argumentativ als kritisch. Verbesserungsvorschläge sollen ja gerade dazu dienen, bestehende Arbeitsweisen zu hinterfragen und effizienter zu gestalten – vor allem dann, wenn es sich um wiederholte, umständliche und ggf. auch unnötige Arbeitsschritte handelt. Nur weil man sich offensichtlich langjährig an eine ineffiziente Methode gewöhnt hat, wird diese nicht automatisch weniger umständlich oder effektiver.

Gerade in Situationen, in denen man nach einem Import viele Dokumente verschiedenen Buchungssätzen zuordnen muss, summiert sich der Aufwand der zusätzlichen Klicks enorm. Hier wäre eine Optimierung des Drag & Drop-Prozesses eine echte Erleichterung und würde die Benutzerfreundlichkeit für alle Anwender – Anfänger wie Erfahrene – eventuell mit konfigurierbarem Drag & Drop-Verhalten – deutlich verbessern.

Viele Grüße

blinky

Kurz und knapp wegen dem gemeldeten Bug:

Es ist i. d. R. nicht nötig gleich mehreren Buchungen ein Dokument zuzuordnen, teils wäre das auch problematisch siehe etwa bei Kontoauszügen.

Daher ist die Belegzuordnung inaktiv, wenn mehrere Buchungen markiert sind. „it's not a bug, it's a feature“

Vielleicht war meine Bug-Meldung missverständlich formuliert, nicht vollständig gelesen worden oder der illustrative Screenshot für die gemeinte Funktion hat mitten im Absatz für Verwirrung gesorgt. Es ging nie darum, einen Beleg mehrere Buchungen gleichzeitig zuzuordnen.
Daher:

1. Meine Bug-Meldung bezog sich darauf, dass selbst nach dem Zurückschalten (also dem Deaktivieren der Mehrfachauswahl) es nicht mehr möglich ist, ein Dokument per Drag & Drop mit einem Buchungsdatensatz zu verknüpfen. Sobald die Mehrfachauswahl einmal aktiviert wurde, scheint ein Neustart des Programms erforderlich zu sein, um die Funktion wieder nutzen zu können.
2. Auch bei aktiver Mehrfachauswahl sollte idealerweise eine Verknüpfung möglich sein, sofern nur ein Buchungssatz ausgewählt ist (nur ergänzend erwähnt, nicht das eigentliche Thema).

Ergänzend

• Läuft Taxpool unter einem Administrator-Konto (durch entsprechende Installation oder Änderung der Einstellungen für die .exe-Datei), und mein Windows-Login erfolgt als normaler Nutzer ("blinky"), funktioniert Drag & Drop überhaupt nicht.
• Läuft Taxpool unter meinem normalen Windows-User, funktioniert Drag & Drop, allerdings mit dem oben beschriebenen Problem.

Hallo zusammen,

vielen Dank für die bisherigen Beiträge.

Ich möchte noch ein paar Punkte ergänzen, die mir bei den verschiedenen DATEV-Formaten und Taxpool aufgefallen sind.

Zwei DATEV-Exportmethoden: Alt (OBE/KNE) und Neu (EXTF/DTVF)

Taxpool unterstützt zwei DATEV-Exportmethoden, das alte OBE/KNE-Format und das neue EXTF/DTVF-Format.

Beide haben unterschiedliche Funktionen und Einschränkungen:

1. Das (obsolete) alte Format (OBE/KNE) ermöglicht laut Handbuch den Export von Kontenbeschriftungen
2. Das neue Format (EXTF/DTVF) unterstützt die Übertragung von Kontenbeschriftungen nur als TSV-Datei, jedoch nicht im spezifizierten DATEV-Format.

Die Taxpool-Dokumentation hebt hervor, dass die Software sowohl für Buchhaltungsanfänger als auch Profis geeignet ist und den Datenaustausch im DATEV-Format unterstützt. Allerdings steht die fehlende Unterstützung der Kontenbeschriftungen im neuen Format im Widerspruch zu diesem Anspruch. Der Hersteller scheint sich der Bedeutung eines sauberen und möglichst gut funktionierenden Datenaustausches bewusst zu sein, doch die aktuelle Implementierung für EXTF/DTVF weist hier Lücken auf, die für OBE/KNE wohl schon berücksichtigt wurden.

Auch der neue Export unterstützt prinzipiell, Konteninformation und Beschriftungen zu exportieren. Dies aber im TSV Format.

Vermutlich wäre bereits ein Wechsel von TSV zu CSV eine sinnvolle Verbesserung, da CSV-Dateien gängiger sind und sich problemlos per Doppelklick öffnen lassen, was den Arbeitsablauf erleichtert. Die Dateiendung "tsv" ist meistens nicht standardmäßig mit Programmen wie Excel verknüpft, was die Handhabung zusätzlich erschwert, insbesondere für Steuerberater und Buchhalter, die selten über tiefes IT-Detailwissen verfügen. Zudem ist die Funktion "Spalten konvertieren" in Excel nicht jedem geläufig, wodurch die Nutzung von TSV-Dateien einen unnötigen manuellen Aufwand bedeutet.

Zusammenfassung und Nutzen

• Das neue EXTF/DTVF-Format unterstützt keine vollständige Übertragung der Kontenbeschriftungen.
• Das alte OBE/KNE-Format bietet diese Möglichkeit und sollte - nach meinem Dafürhalten - auch im neuen, empfohlenen Austauschformat unterstützt werden.
• Bereits ein Wechsel von TSV zu CSV würde den Austausch erleichtern und den Nutzern einige Hürden ersparen.

Weitere Punkte bzgl. den technischen Herausforderungen + Überlegungen:

• Die Kontenbeschriftungen in Taxpool sind wohl nur in deutscher Sprache hinterlegt. Für die meisten Anwendungsfälle dürfte es daher ausreichend sein - gerade im DATEV-Umfeld -, dass die Übernahme der deutschsprachigen Texte erfolgt.
• Eine rückwirkende Änderungen der Kontenbeschriftung für das aktuelle Buchungsjahr analog DATEV erscheint mir (zumindest beim Import) generell sinnvoll, da die Bedeutung eines Kontos sich im Verlauf eines Buchungsjahres nicht ändern sollte. Eine rückwirkende Anpassung zu Beginn des Wirtschaftsjahres wäre aus meiner Sicht vollkommen akzeptabel und würde die Konsistenz der Daten sicherstellen. Eine Änderung darf wohl eher dann erwartet werden, wenn ein Tippfehler korrigiert wird oder ein Konto klarer/besser bezeichnet wird. Eine Änderung der fachlichen Bedeutung sollte wohl eher nicht erfolgen mitten im Buchungsjahr.
• Weitere Kontendetails müssen möglicherweise abgeglichen werden, korrekt. Dennoch gibt es jedoch bereits heute die hilfreiche Funktion, ein Konto als Kopie eines bestehenden, ähnlichen "Nachbar-"Kontos anzulegen. Diese Funktion empfinde ich als sehr nützlich und unterstreicht, dass das Szenario neuer Konten ja prinzipiell schon bedacht und in Teilen berücksichtigt wurde. Wenn dabei nun noch der vorhandene Text automatisch übernommen würde, könnte ein weiterer manueller Schritt entfallen, was den Arbeitsprozess weiter optimieren würde.

Auch hier kann ich nur Verbesserungsvorschläge geben, die mir aus meiner Anwendersicht das Leben erleichtern – eben eine gemeldete "User Story". Aus meiner Sicht würde das ganze Vorgehen etwas "runder" sein und manuelle Extraschritte würden beseitigt/reduziert.

Viele Grüße

blinky