Posts by blinky

Lorette Ja, lässt sich öffnen, aber umständlich (weil in ein ZIP-Archiv gekapselt). Umständlich wirkt auch Dein Umweg eines "Screenshots" als Fotoaufnahme per Handy - da hast Du Dir es vielleicht unnötig kompliziert gemacht.

Wenn Du am gleichen PC Deinen Forenbeitrag schreibst, auf dem auch Taxpool installiert ist und auch eine halbwegs aktuelle Windows-Version hast, folgender Hinweis:

Du kannst Screenshots unter Windows mit der Tastenkombination Windows + Shift + S erstellen. Danach kannst Du den gewünschten Bildausschnitt mit der Maus markieren - der Ausschnitt wird in der Zwischenablage gespeichert. Du kannst das Bild dann mit Strg + V direkt in Deinen Beitrag einfügen - das Bild wird so ohne Zwischenspeichern aus der Zwischenablage übernommen.

Hoffe das funktioniert für Dich so und macht es Dir etwas einfacher

Zur Einordnung: Bei dem Produkt "Nitrokey 3A NFC" handelt es sich einen Hardware-Sicherheitsschlüssel für Zwei-Faktor-Authentifizierung und Verschlüsselung (ähnlich einem YubiKey, falls den jemand kennt) – im Prinzip ein spezialisierter USB-Stick. Gekauft wurden vier Stück. Die werden in der Firma auf die jeweiligen Mitarbeiter eingerichtet (PINs setzen, Schlüssel generieren, bei Diensten registrieren).

(Link zum Produkt entfernt - Taxoloop)

Zum Hintergrund der "Spende": Nitrokey ist eine GmbH, die diese Hardware verkauft. Die Firmware auf den Geräten ist allerdings quelloffen (Open Source). Im Kaufvorgang kann man freiwillig eine Spende für die Weiterentwicklung dieser Firmware hinzufügen. Der Betrag ist wählbar (z.B. "ten" = 10 EUR), und auch die Anzahl lässt sich anpassen – standardmäßig wird sie im Warenkorb auf die Anzahl der gekauften USB-Sticks gesetzt, ist aber offenbar frei änderbar. In diesem Fall sind es vier Spenden à 10 EUR – die Stückzahlen weichen also nicht ab, wie weiter oben behauptet.

Mit der Spende erwirbt man keinen Anspruch auf eine Gegenleistung. Neue Firmware-Versionen kann man auch ohne diese "Spende" herunterladen – ob und wann es überhaupt ein weiteres Update gibt, ist allerdings nicht gewährleistet. Die Spende ist eine freiwillige Unterstützung der Weiterentwicklung, keine Bezahlung für Software oder Updates.

Den Vergleich mit Windows-Software weiter oben würde ich übrigens nicht gelten lassen. Firmware ist hardwarenahe Software, die direkt auf einem Gerät läuft – Windows ist keine Firmware.

Ob sich das steuerlich tatsächlich als "Spende" klassifiziert – also ob der Rechnungsaussteller das in dieser Form vereinnahmen darf – überlasse ich gerne den Buchhaltungsexperten hier 😊 Vielleicht konnte ich ja dennoch etwas zur Klärung des Sachverhalts beitragen.

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

• Formatbeschreibung: https://developer.datev.de/de/file-format…bitorskreditors
• Musterdaten: https://developer.datev.de/de/file-format…mat/sample-data

Taxoloop

Das ist nicht der Fall bei den genannten statistischen Konten (in meinem Fall also 9200 und 9209). Diese werden auch nicht als fehlend angezeigt, habe es soeben extra nochmals mit einer neu angelegten Firma getestet. Ich gehe daher davon aus, dass es hierzu eine Sonderlogik im Programmcode gibt.

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:

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:

Quote from wiko-services.de

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:

Quote from Taxoloop

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.

Quote from modular

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

Dieses Thema hier ist leider noch offen.

Gibt es einen Lösungsansatz wegen der Rückfrage, ob sich die Rechnungen noch im Stapel befinden?

Momentan befürchte ich, alles manuell durchgehen und neu nummerieren zu müssen, würde den manuell Ansatz nach Möglichkiet aber gerne vermeiden.