Posts by blinky

    Erstmal möchte ich festhalten, dass ich es klasse finde, dass man hier im Forum auch buchhalterische Fragen stellen kann und häufig beantwortet kriegt. Das müsste man ja eigentlich nicht erwarten bei einer Software, deren Anwender sich im Idealfall mit Buchhaltung auskennen sollten. Ist bei mir nicht so im Detail ausgeprägt wie bei den anderen Profis hier, aber man lernt ja gerne dazu :)

    Quote

    außer ich finde einen Weg das in 2025 neutral zu buchen

    Ich lese Taxoloops Antwort prinzipiell recht klar im Hinblick auf die Verbuchung der entstanden Kosten. Das diese Aufwand sind scheint mir nachvollbar und sinnvoll.

    Melethron Eventuell geht dabei nur nicht klar genug hevor, dass Du im Hinblick auf Deinen Wunsch schlicht im Jahr 2025 die mit dem Mahnverfahren entstandenen Kosten forderungserhöhend dem Forderungskonto hinzubuchen kannst/sollst.

    Die 51,50 EUR bzw. 93,30 EUR Kostenrechnungen sind zwar Aufwand, aber auch auf dem Forderungskonto des Schulders als Forderungsbetrag einzubuchen (Forderung aus Mahnverfahren, Prozessgebühren o.ä.). So verstehe ich zumindest Deinen "neutral buchen"-Wunsch - ich denke so wäre es sauber abgebildet.

    Sobald der Schuldner dann bezahlt, tilgt er damit die bestehende Forderung, die Du an ihn hast. Aber vermutlich wären die auf das Mahnverfahren entfallenen Kostenanteile dann aber zu dem Zeitpunkt der Schuldnerzahlung als Einnahme auf 4950 Rechts- u. Beratungskosten zu buchen.

    Die Zuordnung Soll/Haben scheint ja korrekt zu sein.

    Ich verstehe Melone145 so, dass es ihm/ihr in Posting #6 um das im hiesigen Screenshot markierte Feld im Einfachen Buchungsmodus geht. Denn in der Tat ist hier Einnahme ausgewählt, wobei korrekterweise Ausgabe ausgewählt sein sollte:



    Edit: Offenbar auch die Dropdown-Liste rechts. Wird nun nur die "Kategorie" nachgepflegt und mit Ändern gespeichert, führt dies vermutlich zu einem falschen Buchungssatz (mit evtl. wieder drehten Konten in Soll/Haben).

    derauchnoch In Deinem Fall ist die Einstellung dann schlicht ""Jedes Mal nachfragen".

    Bei Arbeit mit der Maus ist leider der "Ja"-Knopf der Löschfrage (zweites Popup) direkt unmittelbar unterhalb des ersten Dialogs, bei dem nach dem Löschen der Verknüpfung gefragt wird. Das ist leider sehr unschön.

    Darüber hinaus sollte rein konzeptionell grundsätzlich eine Anwendung nicht ausserhalb ihrer Datenhoheit löschen. Eine auf den Buchungssatz gelegte Datei will ich ja auch nur verknüpfen und nicht im Dateisystem "verschwinden" lassen. Maximal dann, wenn es ein Verschieben wäre im Sinne einer Löschung an der Quelle nach erfolgreichem Upload in in das DMS.

    Taxpool bietet unter Datei --> Import die Funktion "DATEV-Stammdaten Kunden/Lieferanten" an, womit offenbar Debitoren- und Kreditorenstammdaten importiert werden können.

    Leider fehlt derzeit die Möglichkeit eines entsprechenden Exports im DATEV-Format. Dies würde die Datenübergabe an Steuerberater erleichtern, da diese die Stammdaten direkt übernehmen könnten, ohne sie manuell anlegen bzw. nachpflegen zu müssen.

    Daher der Wunsch:
    Implementierung einer Export-Funktion für Kunden- und Lieferantenstammdaten im DATEV-Format (Debitoren/Kreditoren).

    Referenzen

    Danke für den Hinweis. Da ich die Konten nicht explizit selbst angelegt habe, ging ich davon aus, dass die Konten 9200+9209 samt erwähnter Kontenbeschriftung standardmäßig mit der Software ausgeliefert wurden.

    Nun frage ich mich, woher sie stammen.

    Richtig ist, dass ich Buchungssätze, die auf diese Konten buchen, importiert habe. Eventuell gibt es in diesem Kontext ja eine Programmlogik, die die Konten angelegt und in diesem Nummernbereich entsprechend automatisch so benamt. In diesem Fall wäre mein Änderungswunsch für diese Konten von meiner falschen Annahme fehlgeleitet und in der Form obsolet, wenn gleich es natürlich dennoch schön wäre, diese Konten zentral - also in Taxpool standardmäßig - eingepflegt und korrekt beschriftet zu haben.

    Die Kontenbezeichnungen für 9200+9209 habe ich bei mir lokal angepasst.

    Guten Tag zusammen,

    im Rahmen meiner Arbeiten sind mir Differenzen in Taxpool betreffend dem SKR04-Kontenrahmen aufgefallen, die ich wie hier angeregt zusammenfassen möchte:

    Konto

    Aktuell in Taxpool

    Vorschlag

    Referenz

    4836Steuersatz "USt/VSt 16% alt"Steuersatz auf "USt. normal" ändernForen-Thread
    9200Kontenbezeichnung "Statistisches Konto 9200"Kontobezeichnung zu "Beschäftigte Personen" ändernDATEV-Dokument
    PDF-Seite 29 unten (Dokumentenseite 27)
    9209Kontenbezeichnung "Statistisches Konto 9209"Kontobezeichnung zu "Gegenkonto zu 9200" ändern


    Die obige Liste erhebt keinen Anspruch auf Vollständigkeit – sie umfasst lediglich die mir beiläufig aufgefallenen Differenzen.

    Beste Grüße
    blinky

    Hintergrund

    Taxpool ermöglicht unter "Extras → USt-ID zuweisen" die Zuweisung von Umsatzsteuer-Identifikationsnummern auf Buchungssatzebene.

    Die buchungssatzspezifische Zuweisung ist erforderlich, wenn ohne Personenkonten gebucht wird oder beispielsweise mit einem Sammeldebitor/-kreditor (z.B. "Amazon Marketplace"), über den Rechnungen verschiedener einmaliger EU-Kunden/-Lieferanten mit unterschiedlichen USt-IDs gebucht werden. In solchen Fällen wird auf Kreditorenebene bewusst keine USt-ID hinterlegt.

    Problem

    Bei buchungssatzspezifischer USt-ID-Zuweisung bleibt das EXTF-Feld EU-Land u. UStID (Feld 40) beim Export leer, obwohl die USt-ID über "Extras → USt-ID zuweisen" zugeordnet wurde und in der Buchungsliste (Spalte "EU-SteuerID") angezeigt wird.

    Verbesserungsvorschlag

    Beim DATEV-Export sollte folgende Priorität gelten:

    1. USt-ID auf Buchungssatzebene (falls vorhanden)
    2. USt-ID auf Kreditorenebene (falls auf Buchungssatzebene nicht vorhanden)

    Darüber hinaus wäre im Rahmen des DATEV-Exports wohl ein Warnhinweis bei widersprüchlichen USt-IDs sinnvoll, also abweichenden USt-IDs auf Buchungssatz- und Kreditorenebene, sofern beide befüllt sind.

    Hintergrund

    Taxpool bietet unter "Extras → USt-ID zuweisen" die Möglichkeit, Buchungssätzen eine Umsatzsteuer-Identifikationsnummer zuzuordnen.

    Beim DATEV-Export weist das Programm explizit mit einer Warnung "Umsatzsteuer-ID ist notwendig" auf fehlende USt-IDs hin – ein wie ich denke hilfreicher und begrüßenswerter Hinweis:

    Problem

    Beim Import von DATEV-Buchungsstapeln (DTVF-Format) werden die im Feld EU-Land u. UStID (Bestimmung) hinterlegten USt-IDs nicht übernommen, sondern stillschweigend verworfen.

    Verbesserungsvorschlag / Wunsch

    Die im DTVF-Buchungsstapel-Feld EU-Land u. UStID (Bestimmung) vorhandenen Werte sollten beim Import nach Taxpool übernommen und den entsprechenden Buchungssätzen automatisch zugewiesen werden.

    Guten Abend,

    mein Steuerberater wünscht, dass ich ihm keine Buchungssätze übermittle, die er bereits in seinem System (DATEV) vorhanden sind.

    Ausgangssituation
    Mein Steuerberater hat die Buchführung für Januar bis März 2024 durchgeführt und mir diese im DATEV-Buchungsstapel-Format (Datei: DTVF_Buchungsstapel*.csv) überlassen. In dieser Exportdatei war für jeden Buchungssatz eine eindeutige „Buchungs GUID" enthalten:


    Diese Daten habe ich in Taxpool importiert und anschließend ins Journal übernommen. Ab April 2024 übernahm ich die Verbuchung für die normalen Geschäftsvorfälle.

    Meine Fragen in diesem Zusammenhang:

    1. Werden diese aus der DATEV-Datei stammenden Buchungs-GUIDs beim Import in Taxpool dauerhaft gespeichert oder wird anderweitig festgehalten, dass ein Buchungssatz aus einem DTVF-Import stammte?
    2. Kann ich beim Export an meinen Steuerberater einen Filter setzen, der anhand dieser GUIDs (oder einer anderen Markierung) automatisch nur neu erfasste Buchungssätze übermittelt und bereits von ihm erhaltene Datensätze ausschließt? Mir scheint eine solche Funktion nicht zu existieren – sie würde mir aber sehr nützlich erscheinen.

    Mir ist bewusst, dass es laut Hilfe andersherum funktionieren soll (habe es aber nicht getestet). Um dies zu erreichen werden offenbar die Taxpool-internen GUIDs in den hier ersichtlichen Feldern zur DATEV exportiert und beim Reimport wieder zurückgespielt bzw. entsprechend berücksichtigt:


    Allerdings habe ich hier den umgekehrten Fall: Die Daten stammen originär aus DATEV, nicht aus Taxpool.

    Mein Workaround
    Aktuell halte ich meine eigenen Buchungen im Stapel, übernehme sie also nicht ins Journal. So kann ich beim DATEV-Export gezielt nur den Stapel auswählen und das Journal ausschließen – dadurch entstehen keine Dubletten.

    Problem
    Sobald ich auch meine Buchungen ins Journal übernehme, verliere ich diese Trennmöglichkeit. Mein Steuerberater führt für 2024 die Jahresabschlussarbeiten durch und liefert mir die in diesem Zusammenhang erfassten Buchungssätze wieder zurück (einschließlich der Eröffnungsbuchungen für 2025 mit Datum 01.01.2025). Diese muss ich wieder in Taxpool importieren, darf sie jedoch beim nächsten Export nicht erneut an ihn übermitteln.

    Mein Ziel: Ich suche eine etwas "sicherere" Lösung, die beim bidirektionalen Datenaustausch mit meinem Steuerberater Dubletten verhindert – unabhängig davon, ob sich die Buchungen im Stapel oder im Journal befinden. So, dass ich auch selbst mal ins Journal buchen kann und nicht alles nur im Stapel halten muss.

    Vielen Dank!

    Beste Grüsse
    blinky

    Ausgangssituation

    Beim Entfernen einer Belegzuordnung zu einem Buchungssatz erscheint derzeit immer ein Bestätigungsdialog mit der Frage, ob auch die Originaldatei (z.B. PDF) im Dateisystem gelöscht werden soll.

    In der überwiegenden Mehrzahl der Anwendungsfälle besteht jedoch lediglich die Absicht, die Verknüpfung zwischen Buchungssatz und Beleg aufzuheben – nicht aber, die Originaldatei dauerhaft zu löschen. Das gleichzeitige Löschen der Datei aus dem Dateisystem stellt eher den Ausnahmefall dar.

    Die wiederkehrende Abfrage bei jeder Löschung einer Belegzuordnung unterbricht den Arbeitsfluss unnötig und birgt vor allem das Risiko versehentlicher Dateilöschungen durch unaufmerksames Bestätigen.

    Verbesserungsvorschlag

    Implementierung einer konfigurierbaren Einstellung für das Standardverhalten beim Löschen von Belegzuordnungen, mit der Möglichkeit, die Bestätigungsabfrage dauerhaft zu deaktivieren.

    Anregung zur Umsetzung

    • Ergänzung einer neuen Einstellung zum Löschverhalten unter "Verwaltung -> Dokumente" mit den Optionen:
      • "Nur Verknüpfung/Verweis löschen (Datei bleibt erhalten)" – empfohlener Standard
      • "Jedes Mal nachfragen" – bisheriges Verhalten
      • "Verknüpfung und Datei löschen"
    • Alternativ oder ergänzend: Integration einer Checkbox "Diese Auswahl merken" oder "Nicht mehr nachfragen" im bestehenden Bestätigungsdialog
    • Bei Aktivierung der Checkbox: Automatisches Setzen der entsprechenden Einstellung in der Verwaltung


    Dieser Ansatz würde den Arbeitsfluss beim Löschen von Belegzuordnungen verbessern und gleichzeitig das Risiko versehentlicher Dateilöschungen minimieren. Anwender, die das bisherige Verhalten bevorzugen, könnten dies weiterhin nutzen.

    Danke!

    Viele Grüsse
    blinky

    Guten Tag!

    Ich möchte das Verhalten der Software bei der automatischen Zuordnung von Bankumsätzen zu den Personenkonten thematisieren.

    In meinem Beispiel wurde einem Kreditor in den Stammdaten unter "Bank" dessen IBAN hinterlegt (BIC absichtlich nicht ausgefüllt, weil nicht immer übermittelt):

    Der nachfolgende Screenshot zeigt zwei Kontoumsätze mit identischer IBAN:

    In den Einstellungen für die Kontoumsatz-Zuordnung sind Personenkonten mit höchster Priorität konfiguriert:


    Wie ersichtlich wurde am 24.04.2025 eine Zahlung (ausgehende Überweisung) an den Kreditor anhand der IBAN automatisch dem Personenkonto zugeordnet.

    Am 28.10.2025 erfolgte eine Erstattungszahlung (Gutschrift) vom selben Kreditor, die trotz identischer IBAN nicht automatisch dem Personenkonto zugeordnet wurde – hier war eine manuelle Zuordnung erforderlich.

    Die automatische Zuordnung differenziert bei der IBAN-Identifikation offenbar zwischen Zahlungsrichtung bzw. Debitor-/Kreditor-Eigenschaft. Die IBAN allein wird nicht als hinreichendes Zuordnungskriterium behandelt, wenn die Zahlungsrichtung nicht der Art des Personenkontos entspricht.

    Ich frage mich, ob diese hardkodierte Trennung tatsächlich erforderlich ist oder ob eine Aufweichung – zumindest als optionale Einstellung – nicht sinnvoll wäre. Eine IBAN-basierte Zuordnung unabhängig von der Zahlungsrichtung erscheint mir grundsätzlich akzeptabel, sofern nicht auch ein (in diesem Fall) Debitor mit derselben IBAN existiert.

    Beste Grüsse
    blinky

    Hallo Taxoloop,

    danke für die ausführliche Erklärung zu den fachlichen Unterschieden zwischen Belegnummer, Rechnungsnummer und Fremdbeleg. Diese Unterscheidung ist mir bewusst – ich hatte die Begriffe ja selbst aufgelistet, um Missverständnissen vorzubeugen, da in vorherigen Beiträgen von Rechnungsnummern die Rede war, obwohl ich im Eingangspost und auch danach ausschließlich von Belegnummern sprach:

    Man müßte ja dann auch alle jetzt neu entstandenen Rechnungen mit neuer Rechnungsnummer an die Kunden versenden.

    Daraufhin hatte ich in Post #8 klargestellt, dass ich Taxpool nicht zur Rechnungserstellung nutze, sondern Rechnungen lediglich über "Kunden/Lieferanten → Einfache Erfassung von Rechnungsdaten" erfasse. Dennoch:

    Wenn also Rechnungen (und damit auch OPs) mit gleichen Rechnungsnummern erstellt wurden, wird man die falsch eingegebenen Rechnungsnummern in der Faktura korrigieren müssen und nicht erst in den daraus erstellten Buchungen.

    Es geht mir nicht um Rechnungsnummern, sondern ausschließlich um die Belegnummern. Hauptsächlich deshalb habe ich die Begriffsliste in Post #12 niedergeschrieben, weil ich das Gefühl hatte, dass die Begriffe teilweise vermischt werden.


    Zur Redundanz

    Mein Punkt zur Redundanz bezog sich nicht auf die fachliche Ebene (dass Belegnummer, Rechnungsnummer und Fremdbeleg unterschiedliche Informationen sind – das ist klar), sondern auf die technische Ebene:

    Wenn ein Eintrag unter Kunden/Lieferanten mit einem Buchungssatz verknüpft ist, existiert die Belegnummer (und auch die Fremdbelegnummer) an zwei Stellen in der Datenbank – einmal im Rechnungsdatensatz, einmal im Buchungssatz. Diese redundante Datenhaltung ermöglicht rein datenkonzeptionell - also vom Datenmodell her - , dass unterschiedliche, widersprüchliche Werte gespeichert sein könnten. Konsistent bleibt das nur, wenn die Synchronisation immer und überall sauber durchgeführt wird. In einer Konsistenzprüfung (Gegenüberstellung der Werte bei korrekter Datensatz-Verknüpfung) würden Abweichungen auffallen. Redundante Datenhaltung ist grundsätzlich möglich, erfordert aber konsequente Synchronisation – noch besser ist es, solche Redundanzen bereits im Datenmodell zu vermeiden, wann immer möglich.

    Und genau das passiert hier: Die Synchronisation funktioniert teilweise, aber eben nicht durchgängig zuverlässig. Bei manchen Änderungen werden die gespiegelten Felder in den verknüpften Datensätzen aktualisiert, bei anderen nicht.

    Und noch zu [1] / Belegkreise bei Zahlungen: Die Belegnummer der Zahlungsbuchung wird im Rahmen der OP-Verknüpfung auf die der Rechnung gesetzt – siehe den ergänzt eingepflegten Link in meinem Posting #11.

    Viele Grüsse
    blinky

    Taxoloop

    Ich habe über die Vorschau hinaus nun einmal die Neunummerierung der Belege ausgeführt.
    Unter Kunden/Lieferanten finden sich in den jeweiligen Rechnungssätzen weiterhin die alten Belegnummern (z.B. RE-24, siehe links im Bild zuvor), während in der Buchungsliste RE-3 erscheint.

    Insofern hast Du (für mich bedauerlicherweise) recht. Die Daten werden offensichtlich intern mehrfach/redundant gehalten. Das ist immer eine Schwachstelle/Fehlerstelle für potentielle Inkonsistenzen, die immer genau dann zu Tage tritt, wenn die Daten per Programmcode nicht richtig synchronisiert werden.

    Dennoch ganz kurz zu den Begrifflichkeiten, da ich das Gefühl habe, dass diese hier teilweise vermischt werden:

    1. Belegnummer
      1. Technisch als Datenfeld in der Buchungsliste - in der Anwendung möglicherweise separat gehalten als extra Datenfeld für das Resultat als Text: "RE-24", dann Belegkreis "RE" und Zähler "24"
      2. Technisch als separate Datenfelder in Kunden/Lieferanten: Belegkreis und Zähler
    2. Rechnungsnummer (separates Datenfeld in Kunden/Lieferanten. Hat nichts mit der Belegnummer zu tun, Allerdings würde man bei Ausgangsrechnungen die Belegnummer wohl zur Ausgangsrechnung passend setzen, also RA-1000 bei der Rechnungsnummer 1000)
    3. Fremdbeleg
      1. separates Datenfeld in Kunden/Lieferanten
      2. möglicherweise(?) auch nochmals auf Ebene der Buchungssätze selbst vorhanden

    Und nur um es klarzustellen: Ich will keine neue Rechnungsnummern vergeben (weder Eingang noch Ausgang), sondern nur die Belegnummern glattziehen.

    Momentan werde ich das wohl am Besten so machen, dass ich alle Daten exportiere, in einer Excelliste sauber durchnummeriere und dann manuell alles wieder im Programm neu eingebe - das eben auch direkt an den verschiedenen Stellen, wo es redundante Datenfelder gibt, weil ich leider nicht auf die Konsistenz vertrauen kann. ( modular Es wäre wirklich schön, wenn das "gehärtet", also verbessert werden könnte, so dass man sich über die Datenkonsistenz nicht so sehr Sorgen machen und manuell kümmern muss).

    Danke euch allen!

    modular

    Dankeschön -- soweit klappt das bei mir auch teilweise, keine Frage. Es klappt eben nur nicht vollständig konsistent.
    Habe es mal mit Deinen Einstellungen getestet:


    Auch bei Inaktivierung von "Manuelle Belegnummerierung nicht ändern" bleibt das identisch.

    Zu [1]: Da haben wir einen Link in die wenigen Buchungen vom 31.12.2023 --- die Belegnummer wird dadurch bereits nicht eindeutig. Das hatte ich schon mal gemeldet und befürchte, dass das nicht sauber ist und beim Übertrag der Daten (DATEV) im Hinblick auf die OPOS Probleme verursachen dürfte. Darum ging es mir hier aber gar nicht primär, erwähne es aber nochmal, da hier ersichtlich.

    Zu [2]: Die Buchungen vom 16.01.2024 und 01.02.2024 sind in Taxpool per OP-Funktion verknüpft. Zwar erhält die Buchungen vom 16.01.2024 eine neue Nummer, der verknüpfte Datensatz vom 01.02.2024 aber nicht. Bei etlichen anderen Buchungssätzen funktioniert es, aber es gibt diverse weitere Buchungssätze ("Paare", also Eingang und Ausgang), bei denen es eben nicht klappt und die Belegnummer wie "festgetackert" ist.

    Auch das Löschen der Zahlungszuweisung über OPV und erneute Zuweisung ändert daran nichts. Der zweite Buchungssatz bleibt bei RE-1.
    Wie gesagt, dass ist nicht das einzige Vorkommnis, bei dem es keine Neunummerung gibt. Bei einigen anderen Buchungs"paaren" würde es laut Vorschau aber einwandfrei klappen.

    Ferner ein möglicher Bug, auch wenn hier thematisch auch separat:
    Ändere ich die Fremdbelegnummer in Kunden/Lieferanten, so wird der Buchungssatz vom 16.01.2024 entsprechend aktualisiert. Der Fremdbeleg vom 01.02.2024 aber nicht. Im Rahmen der OP-Verknüpfung findet aber auch eine Aktualisierung des Fremdbelegs bim 01.02.2024 statt. Das wirkt ebenfalls inkonsistent. Beim DATEV-Export scheint eine erweitere Routine aber die Daten über die Verknüpfung aufzulösen, dass dass ich den Fremdbeleg aus dem 16.01.2024 erhalte (müsste ich nochmal testen, ich glaub aber, dass es so war).

    Hallo zusammen,

    vielen Dank für eure Rückmeldungen! Es liegt offenbar ein Missverständnis vor, weil ich das im ersten Posting wohl nicht genau genug erklärt hatte: Ich nutze Taxpool nicht zur Rechnungserstellung. Die Rechnungen (Eingang und Ausgang sowieso) werden extern erzeugt und ich erfasse sie lediglich über "Kunden/Lieferanten → Einfache Erfassung von Rechnungsdaten".

    Da viele dieser Rechnungen wiederkehrend die gleichen Beträge haben, hatte ich die Kopierfunktion genutzt – dabei wurden leider die Belegnummern mitkopiert.

    den Belegkreis der Rechnungen auswählst

    Vielen Dank für den Hinweis mit der Dropdown-Liste bei den Belegkreisen – die war mir tatsächlich nicht aufgefallen.

    Leider erreiche ich auch mit dieser Vorgehensweise das Ziel nicht. Egal welche Einstellungen ich in der Programmmaske "Belege neu durchnummerieren" wähle – wenn ich den Belegkreis "RE" auswähle und die Vorschau erstelle, erhalte ich trotzdem Dubletten und Fehlzuordnungen bei der Vergabe der neuen Belegnummern.

    Diese Dubletten gibt es sogar innerhalb den grünen Datensätzen, also denen, die laut Vorschau neu nummeriert würden. Beispielsweise wird RE-27 sechs mal vergeben – für 3 verschiedene Rechnungen mit den jeweils zugehörigen Zahlungsausgängen vom Bankkonto. Ich hätte hier drei verschiedene Belegnummern erwartet.

    Zusätzlich sehe ich auch keinen Unterschied im "Neu durchnummerieren"-Ergebnis, egal ob ich das Häkchen rechts neben "Belegkreis/Belegnummer" im Bereich der Rechnung (unter Kunden/Lieferanten) aktiviert habe oder nicht.

    Wenn man in Taxpool nach „Belegdatum" aufsteigend sortiert, werden die Buchungssätze einer Splitbuchung derzeit in scheinbar zufälliger Reihenfolge angezeigt.

                  

    Schöner wäre es, wenn die Darstellung konsistent erfolgen würde: Die Hauptbuchung (mit dem „+"-Symbol) sollte meinem Dafürhalten nach zuerst erscheinen, gefolgt von den zugehörigen Teilbuchungen (mit dem „−"-Symbol). Für die Reihenfolge der Teilbuchungen untereinander habe ich keine spezifische Präferenz – ob schlicht nach Erfassungsreihenfolge oder primär nach Teilbetrag absteigend (mit Erfassungsreihenfolge als sekundärem Kriterium bei gleichen Beträgen), wäre mir gleich.

    Interessanterweise wird die „korrekte" Sortierung hergestellt, sobald man anschließend den Button „Sortieren" (neben OP/OPV) anklickt.

    Vielleicht ließe sich dieses Verhalten direkt beim Klick auf die Spaltenüberschrift „Belegdatum" integrieren – der zusätzliche Klick erscheint unnötig.

    Wie im Titel angedeutet: nur Kosmetik, nicht dringend. Vermutlich aber mit wenig Aufwand umsetzbar.

    Danke + Gruß
    blinky

    Hallo zusammen!

    Wenn auch etwas spät, so habe ich mich hiermit doch noch einmal beschäftigt. Daher:

    Danke für den Hinweis auf § 146 AO – aber ich glaube, der greift hier nicht ganz.

    § 146 Abs. 1 AO verlangt, dass Buchungen „einzeln, vollständig, richtig, zeitgerecht und geordnet" vorzunehmen sind. Von einer Belegnummer steht da nichts.

    Die GoBD sind hier differenzierter. Rz. 77 beschreibt, was ein Beleg enthalten soll – darunter eine „eindeutige Belegnummer (z.B. Index, Paginiernummer, Dokumenten-ID)". Aber selbst dort steht: „Sofern die Fremdbelegnummer eine eindeutige Zuordnung zulässt, kann auch diese verwendet werden."

    Entscheidender ist Rz. 64:

    „Zur Erfüllung der Belegfunktionen sind deshalb Angaben zur Kontierung, zum Ordnungskriterium für die Ablage und zum Buchungsdatum auf dem Papierbeleg erforderlich. Bei einem elektronischen Beleg kann dies auch durch die Verbindung mit einem Datensatz mit Angaben zur Kontierung oder durch eine elektronische Verknüpfung (z. B. eindeutiger Index, Barcode) erfolgen. Ein Steuerpflichtiger hat andernfalls durch organisatorische Maßnahmen sicherzustellen, dass die Geschäftsvorfälle auch ohne Angaben auf den Belegen in angemessener Zeit progressiv und retrograd nachprüfbar sind."

    Das bedeutet konkret:

    Bei Papierbelegen kann man Kontierung und Belegnummer draufschreiben – muss aber nicht, wenn die organisatorischen Maßnahmen stimmen. Und bei elektronischen Belegen (also auch eingescannten PDFs) genügt die „elektronische Verknüpfung" – also der technische Verweis in der Datenbank (von Taxpool), der den Buchungssatz mit dem hinterlegten/zugehörigen Beleg verbindet.

    Und genau hier liegt mein Punkt:

    Die Buchungsnummer – also die interne ID, die Taxpool für jeden Buchungssatz automatisch vergibt – existiert immer, unabhängig von den Einstellungen (also ob Belegnummerkreis/Belegnummer aktiv oder inaktiv). Wenn ich zusätzlich den Beleg als PDF direkt an den Buchungssatz hänge, ist die Zuordnung durch diese Verknüpfung bereits gegeben.

    Das Feld Belegnummer in der Buchungsmaske ist davon unabhängig – ein separates Feld, das traditionell dazu dient, eine Nummer auf den Papierbeleg zu schreiben, um ihn im Ordner wiederzufinden.

    Mein Problem
    Wenn ich die Belegnummernfunktion aktiviert habe – weil sie bei Eingangs- und Ausgangsrechnungen durchaus Sinn ergibt – dann erzwingt Taxpool bei jeder Buchung eine Nummer in diesem Feld. Auch dort, wo sie keinen Sinn hat.

    Bei einer AfA-Buchung oder einer USt-VA-Zahlung steht dann z.B. „1" oder „SO-0001" im Belegnummernfeld. Aber diese Nummer führt nirgendwohin – kein Beleg ist so beschriftet, kein PDF so benannt. Sie verweist ins Leere.

    Das widerspricht meinem Verständnis von sauberer Datenstruktur: Ein Verweis sollte auf etwas Existierendes zeigen. Eine Belegnummer ohne zugehörigen Beleg ist wie ein Wegweiser in eine Richtung, wo nichts zu finden ist. Das ist nicht nur überflüssig – es suggeriert auch eine Ordnung, die nicht existiert, und untergräbt damit genau die Nachvollziehbarkeit, die eine Belegnummer eigentlich herstellen soll.

    Deshalb mein ursprünglicher (zweiter) Gedanke:
    Es wäre sinnvoll, wenn man das Belegnummernfeld bei einzelnen Buchungen leer lassen könnte – auch bei aktivierter Belegnummernfunktion. Ein Mittelweg zwischen „komplett deaktivieren" und „überall erzwingen".

    Dass mein Buchhalter in DATEV seit über 10 Jahren ohne manuell erfasste Belegnummern arbeitet, zeigt zumindest, dass es in der Praxis auch anders geht und offenbar nicht erforderlich ist.

    Ich würde mir daher zeitnah erlauben, dies als separaten Verbesserungsvorschlag zu erfassen – sofern nicht bereits dieser Thread dorthin verschoben wird.

    Viele Grüsse!
    blinky