Digitale Belege an bereits festgeschriebene Buchungsstapel anhängen

[#1]

Guten Tag alle miteinander,

Wir sind nun seit gut 18 Monaten dabei unsere Buchhaltung vollständig zu Digitalisieren.

Nach einem relativ langen Weg über ISWL Beleg2Buchung und Belegtransfer sind wir auch mittlerweile auf einem sehr guten Weg. Nun kommt das Problem was scheinbar schon lange herrscht. Das nachträgliche Anhängen von Belegen an bereits festgeschriebene Buchungsstapel. 

Es gibt schon so einige Community-Beiträge zu diesem Thema, allerdings immer ohne einen Erfolg. (meines Wissens nach). Nun sind die Beiträge alle schon relativ alt und ich habe gehofft das es hier vielleicht mittlerweile einen Weg gibt. Dazu könnte ich eure Hilfe gebrauchen.

Nur nochmal ein paar Eckdaten:

- Die Belege existierten auch schon vor Festschreibung! (auch bei uns im Haus, diese haben nur die Digitalisierung "verpasst" oder wurden falsch benannt/ abgespeichert [falscher Pfad/ Monat etc.])

- Ausgangsbelege aus dem angeschlossenen DMS konnten nicht erstellt werden und müssen nachträglich angehangen werden. (Passiert leider gelegentlich "BUGS") soll bedeuten, kann definitiv passieren.

Bevor mir einer sagt ich soll dann einfach noch nicht festschreiben:

- Wir sind Vertragshändler einer großen Marke, diese erfordert eine Meldung der Buchhaltung, diese Meldung kann nur erfolgen, sofern festgeschrieben wurde. (nicht hinterfragen, ist leider einfach so!)

Nach diversen Recherchen kann ich nichts finden was dagegen sprechen würde (jedenfalls GOB bzw. GOBD seitig)

Ich hoffe auf Hilfe!

Gruß

Eric Templer

Kategorie angepasst von @Angelika_Roßmeisl 

[#2]

---

@EricTempler1810 schrieb:

Nun sind die Beiträge alle schon relativ alt und ich habe gehofft das es hier vielleicht mittlerweile einen Weg gibt.

---

Nö, sonst wäre diese Idea auf umgesetzt gesetzt worden: Beleg an festgeschriebene Buchung anhängen 

[#3]

Dann sollten wir als Community diese Thema noch einmal anstoßen, denn notwendig wäre dieses allemal!

LG

[#4]

Dann rufen Sie Ihre Bitte  in die großen Hallen der DATEV, aber ausser Ihrem Echo werden Sie nix hören ... so viele Dinge die zu tun wären, aber niemand geht sie an. 

Ich freue mich über Ihren Optimismus, aber fürchte Sie werden sich die Hörner auch noch abstoßen.

BTW und Edith: Das "Anhängen" hat auch nix mit Unternehmen online zu tun, sondern passiert vielmehr in KaReWe für die, oh Wunder oh Wunder, keine DATEV Ideas gibt.

[#5]

---

@EricTempler1810 schrieb:

denn notwendig wäre dieses allemal!

---

Sagst Du 😜. Okay und 181 andere auch aber bei wie vielen DATEV Anwendern in Deutschland? Wir sehen uns wieder, wenn wir Rente beziehen ✌️😆. Behalte Deine Euphorie! 

[#6]

---

@EricTempler1810 schrieb:
[...]
Nun sind die Beiträge alle schon relativ alt
[...]

---

... "alt" ist relativ. 

Wenn schon wenige Wochen als "alt" bezeichnet werden, dann wäre die Tochter eines Verwandten auch schon "alt" 

Ich selbst habe vor kurzem auch schon eine ähnliche Frage in einem Thread diskutiert

... egal ..

Das Problem ist, dass eine Belegverknüpfung technisch eine "GUID" ist, also eine 'einmalige' Identifikationsnummer, die im REWE-Buchungsstapel eingetragen wird

Wenn der Buchungsstapel aber bereits festgeschrieben ist, kann man ihn mit Datev-Bordmitteln nicht mehr ändern.

Rein technisch sehe ich kein Problem, die Beleglinks zu erzeugen und dem Buchungsstapel hinzuzufügen, aber nicht mit 'offiziellen' Datev-Mitteln

... man müsste den festgeschriebenen Buchungsstapel nämlich löschen, die Beleglinks hinzufügen und ihn dann wieder importieren und verarbeiten

Das dürfte wohl hart mit der GoBD kollidieren

Nachtrag:

rein für Auswertungszwecke, z.B. für die nachträgliche Suche nach Buchungen und Belegen, unabhängig von der 'offiziellen' Buchführung, würden mir schon ein paar Möglichkeiten  einfallen

[#7]

Als Workaround (natürlich nur, wenn es Einzelfälle sind, sonst wird man wahnsinnig!):

Im Belege buchen (am besten natürlich in einem Stapel des gleichen Zeitraums, aber geht auch im aktuellen Stapel):

Alte Buchung finden -> Buchung kopieren (F8) -> Beleg anhängen -> Buchung speichern -> Alte Buchung stornieren.

LG

Manuela

[#8]

@EricTempler1810 , meinen Sie wirklich, DATEV wird den Workaround von @mjachert für den kompletten Bestand eines Jahres ermöglichen?

Wie @mjachert ja schon beschrieb, für "einzelne Sachverhalte" geht das wohl, ansonsten "Wahnsinn"...

[#9]

alt ist bei Technik, sowohl in Hard- als auch Software, immer "relativ". 😉

Jetzt bin ich in den Datev Begrifflichkeiten noch nicht ganz so fit.

Allerdings IT-Technisch:

- Von der IT-Warte aus besteht kein Problem einen ,wir nennen ihn mal, unsichtbaren REWE-Buchungsstapel zu erstellen. Dieser soll ja nicht tun, außer diese Belegverknüpfung zu ergänzen/ speichern.

Ansonsten soll es ja definitiv Möglich sein den "offiziellen Weg" (Generalumkehr) so zu vereinfachen das über einen einzelnen Button alle Schritte durchgeführt werden. Nur dann wieder das Problem, ein Haufen Storno Sätze die spätestens in einem Ausdruck wieder auftauchen. Höchst unbefriedigend!

Lösungsvorschlag:

Butten ergänzen, welcher den Prozess auf einen Button/ Shortcut beschränkt. Pauschales ausblenden der Stornosätze die über diesen Button gelaufen sind und somit nur noch in der Historie angezeigt werden.

[#10]

@EricTempler1810 ,

wie oben im Nachtrag angedeutet, könnte ich mir vorstellen, dass für eigene Auswertungszwecke eine Art 'Schatten-Buchungsstapel' generiert werden kann, der dann die Digitalen Belege zu den Buchungen anzeigen kann

[#11]

---

Wie @mjachert ja schon beschrieb, für "einzelne Sachverhalte" geht das wohl, ansonsten "Wahnsinn"...

Ich bleibe beim Wahnsinn:

nimmt man einfach nur einen Wahrscheinlichkeit, wie oft dieses Phänomen vorkommt. Sagen wir mal 2,00 %?

Bei dann 1000. Buchungssätzen kommt es 20 mal vor.

Dann ist in unserem spezifischen Fall der DMS Anbindung das Problem der BUGS. 

DMS kann Sie nicht beheben, also bleibt nur das manuelle Anhängen.

Also nochmal ca. 20 - 30 Buchungsätze zusätzlich.

Also von Wahnsinn kann man dann schon sprechen.

[#12]

---

@EricTempler1810  schrieb:

 Nur dann wieder das Problem, ein Haufen Storno Sätze die spätestens in einem Ausdruck wieder auftauchen. Höchst unbefriedigend!

---

Wenn Sie vor dem Ausdruck des Kontoblatts in den Eigenschaften rechts "stornierte Buchungen ausblenden" aktivieren, werden die Storno-Buchungen nicht mit angedruckt. ☝️

[#13]

---

@mjachert  schrieb:

Wenn Sie vor dem Ausdruck des Kontoblatts in den Eigenschaften rechts "stornierte Buchungen ausblenden" aktivieren, werden die Storno-Buchungen nicht mit angedruckt. 

---

Okay, kann man so machen.

Löst aber nicht das Problem.

[#14]

Man kann in DATEV auch Buchungssätze erzeugen, deren Gegenkonto und Konto gleich sind.

Belege, die jetzt nicht zugeordnet sind können so in der Buchhaltung mit eingegliedert werden. Dadurch hat man zumindestens den Betrag, die Belegnummer und das Datum als gleiches Suchkriterium zu ursprünglichen Buchungssatz ohne Beleg.

Nachteile:

JVZ auf Debitoren und Kreditoren werden um die jeweiligen Beträge höher. Es gibt Prüfungsprogramme, die das eventuell bemängeln könnten.

Zukünftige Buchungsvorschläge greifen eventuell darauf zu und müssen dann korrigiert werden.

Vorteil: 

Es muss nichts storniert werden und man findet die Belege aufgrund der Suchkriterien relativ schnell wieder.

[#15]

Nachtrag:

nach dem nochmaligen, laaangsaaamen Lesen des Ausgangsbeitrags nehme ich meinen Vorschlag zurück 😎

Ich war davon ausgegangen, dass es um das nachträgliche Erzeugen und Hinzufügen von Belegverknüpfungen in großen Buchungsstapeln geht, die noch aus der Zeit vor dem Digitalen Belegbuchen stammen ...

... aber es geht ja 'nur' um Belege, die während der Aktion mit "ISWL_Beleg2Buchung" 'gerade nicht auffindbar' waren oder aus sonstigen Gründen nicht zugeordnet wurden.

Mein Vorschlag ging in eine ganz andere Richtung.

Mir geht es um die nachträgliche Digitalisierung und Visualisierung von alten weißen ... ähm ... großen Belege-Beständen

[#16]

Nachtrag:

... aber ein Teilproblem hätten wir gemeinsam

Ich suche nämlich momentan auch nach einem Workaround, wie man zu einem vorhandenen Buchungsstapel komfortabel und schnell die noch fehlenden Belege auflisten kann.

Dann würde man sicher vor der Aktion mit "ISWL_Beleg2Buchung" noch nach den fehlenden Belegen suchen und sie in die zu verknüpfende Sammlung hinzufügen und bräuchte dann nicht nach der Aktion mit "ISWL_Beleg2Buchung" große Klimmzüge machen

... mit Hilfe von excellenten 'Handgriffen' gelingt es mir zwar, aber man müsste das als 'slow working' bezeichnen, eine ungeliebte Technik 😅

Ich sollte mal wenigstens versuchen, meinen 'handgestrickten' Workaround mit einem Excel-Makro zu 'automatisieren'. 

Leider hat ein ehemaliges Community-Mitglied, ein ausgewiesener VBS-Spezialist, der Community den Rücken gekehrt 😣

[#17]

Dann muß man halt gleich auch noch eine Generalumkehrbuchung zur Dummy-Buchung hinzufügen.

[#18]

---

@EricTempler1810 schrieb:
[...]

Nur nochmal ein paar Eckdaten:

- Die Belege existierten auch schon vor Festschreibung! (auch bei uns im Haus, diese haben nur die Digitalisierung "verpasst" oder wurden falsch benannt/ abgespeichert [falscher Pfad/ Monat etc.])

- Ausgangsbelege aus dem angeschlossenen DMS konnten nicht erstellt werden und müssen nachträglich angehangen werden. (Passiert leider gelegentlich "BUGS") soll bedeuten, kann definitiv passieren.

[...]

---

in einem der nächsten Posts steht ...

Jetzt bin ich in den Datev Begrifflichkeiten noch nicht ganz so fit.

Allerdings IT-Technisch

... diese beiden Aussagen klingen nicht so, als wären die IT-Prozesse im Unternehmen stabil bzw. gut durchdacht

Aus meiner Sicht sollte es doch möglich sein, zu erkennen, welche Belege für den aktuellen Buchungsstapel noch fehlen.

Es wäre einen Versuch wert, diese Belege als "Dummy-Belege" mit korrekter Belegnummer zu generieren und zusammen mit den übrigen Belegen per "ISWL_Beleg2Buchung" zu verknüpfen und hochzuladen. Dann hätte man zumindest schon mal die jeweiligen Beleglinks im Buchungssatz stehen, mit denen man 'arbeiten' könnte, evtl. auch nach der Festschreibung

Ich werde selbst auch dieser Idee weiter nachgehen, da ich hier diverse Chancen sehe

[#19]

---

@vogtsburger  schrieb:

... diese beiden Aussagen klingen nicht so, als wären die IT-Prozesse im Unternehmen stabil bzw. gut durchdacht

Die "Unterstellung" weise ich gern zurück. Wie es klingt und wie es nicht klingt, sind nicht Bestandteil des Problems. Es geht um ein Problem, welches sich nun doch schon eine ganze Weile zieht.

Aus meiner Sicht sollte es doch möglich sein, zu erkennen, welche Belege für den aktuellen Buchungsstapel noch fehlen.

Es wäre einen Versuch wert, diese Belege als "Dummy-Belege" mit korrekter Belegnummer zu generieren und zusammen mit den übrigen Belegen per "ISWL_Beleg2Buchung" zu verknüpfen und hochzuladen. Dann hätte man zumindest schon mal die jeweiligen Beleglinks im Buchungssatz stehen, mit denen man 'arbeiten' könnte, evtl. auch nach der Festschreibung

Ich werde selbst auch dieser Idee weiter nachgehen, da ich hier diverse Chancen sehe

Ich habe nie behauptet, das es nicht möglich sei, zu erkennen, welche Belege fehlen. Ich habe in diesem Rahmen ein anderes Problem welches aber hier nichts zur Sache tut. Fest steht, wir wünschen uns diese Funktion!

---

[#20]

Ich fürchte mit der Ablehnung dieser Idea Beleg an festgeschriebene Buchung anhängen  hat sich das Thema für die DATEV (erst einmal) erledigt.

[#21]

---

@sokru  schrieb:

Ich fürchte mit der Ablehnung dieser Idea Beleg an festgeschriebene Buchung anhängen  hat sich das Thema für die DATEV (erst einmal) erledigt.

---

... ja, das ist zu befürchten, aber das muss uns ja nicht daran hindern, weiter selbst nach Möglichkeiten und/oder 'Notlösungen' zu suchen

... evtl. gilt ja das Motto:

"steter Tropfen höhlt den Kalk" ... oder so ähnlich

[#22]

Was noch geht, bestimmt aber Ihr Problem nicht lösen wird:

je eine leere Seite an die Buchung vor der Festschreibung hängen, da kann dann auch nach der Festschreibung eine Folgeseite(n) an die leere Seite drangehangen werden

Wenn Sie aber Belege importieren usw., wird das maximal für einzelne wenige Belege praktikabel sein.

[#23]

@guenther ,

ja, genau das hatte ich hier und in der IDEA zum selben Thema vorgeschlagen, und zwar, dass man jede Buchung, die einen Beleg braucht, wenigstens mit einem Dummy-Beleg verknüpfen sollte, den man dann später entweder ersetzen oder oder weitere Seiten hinzufügen kann.

... aber es wird von einzelnen Community-Mitgliedern bezweifelt, dass das Hinzufügen von Seiten oder das Ersetzen des Dummy-Belegs nach der Festschreibung des REWE-Buchungsstapels noch der GoBD entspricht und dass dass diese Funktion aus diesem Grund von der Datev nicht zugelassen wird.

Nur ein Beispiel:

Warum sollte es nicht möglich sein, einen unleserlichen, schlecht gescannten, falschen oder unvollständigen Beleg nachträglich noch zu ersetzen oder zu ergänzen ?

Meinetwegen könnte der alte Beleg ja noch zwangsweise aufbewahrt bleiben, z.B. zu Dokumentationszwecken.

An der REWE-Buchung bzw. am festgeschriebenen Buchungsstapel wird ja nichts geändert

[#24]

Deswegen hier in der Community schon oft erwähnt "Würgarround". 

Das gibt es in der Datev Welt leider oft.  Im Zweifel @andreashausmann fragen, wenn auch er nur den beschriebenen 'würgarround" kennt gibt es leider keinen besseren Weg. 

Edit: Ich masse das im übrigen auch so, weil passiert ja immer wieder das in der lfd. Fibu ein Beleg fehlt, kommt dann ein paar Monate später rein. Stapel festgeschrieben also GU alter Buchungsatz und Neueingabe mit Belegverknüpfung dann passt es ist aber ausgesprochen lästig. 

[#25]

Mir ist hier kein Work-Around bekannt.

Work-Arounds haben immer das große große Problem, dass dies Lösungen sind, die vom Software-Anbieter nicht vorgesehen sind, d.h. jedes Update kann dafür sorgen, dass der Work-Around nicht mehr funktioniert. Support gibt es hier nicht, da die Funktion ja vom Software-Anbieter nie vorgesehen war. Ergo schauen wir in diesem Fall in die Röhre.

Daher sind Work-Arounds grds kritisch zu sehen und sollten nie Bestandteil von wichtigen Arbeitsabläufen sein.

Mein Work-Around, weitere Belege an einen bestehenden zu heften, auf den verwiesen wurde, hat bisher auch nie durchgehend funktioniert. Mein aktueller Stand ist, dass dieser derzeit nicht mehr funktioniert.

Mir persönlich ist eine möglichst effiziente Arbeitsweise wichtig. Daher ergibt sich für mich gar nicht die Fragestellung Belege nachträglich mit Buchungssätzen zu verknüpfen.

Entweder handelt es sich bei der nachträglichen Beschäftigung mit einer Buchung um eine Korrektur, weil eine korrekte zum Vorsteuerabzug berechtigte Rechnung nachgereicht wurde -> GU und gut

oder die Buchung bleibt so wie Sie ist 🙂

[#26]

---

@andreashausmann  schrieb:

Entweder handelt es sich bei der nachträglichen Beschäftigung mit einer Buchung um eine Korrektur, weil eine korrekte zum Vorsteuerabzug berechtigte Rechnung nachgereicht wurde -> GU und gut

oder die Buchung bleibt so wie Sie ist 🙂

---

Wie bereits weiter oben erläutert, handelt es sich um Belege, welche den Digitalisierungsdurchlauf "verpasst" haben. Also Belege die Bereits im Haus sind.

Notwendigkeit haben nun schon so einige geäußert.

Relevanz ist vorhanden, da als nächster Schritt die Vernichtung der originalbelege ansteht, was natürlich ohne die Vollständigkeit innerhalb des Datev nicht vorgenommen werden kann.

LG

Eric

[#27]

Mir stellt sich die Frage, wie der Beleg verbucht wird, wenn der Digitalisierungsdurchlauf verpasst wurde?

Ich würde hier ggf den Prozess so gestalten, dass der Beleg nicht mehr fehlt und bei den fehlenden Sachverhalten mit Generalumkehr korrigieren und den Beleg nachbuchen.

Das mag jetzt an dieser Stelle sehr pessimistisch klingen, aber ich gehe nicht davon aus, dass DATEV die Möglichkeit Belege nachträglich anzuheften je anbieten wird.

Wie vorher schon beschrieben, wird der Verweis auf den Beleg mit dem Buchungssatz festgeschrieben.

Zur Schaffung der Möglichkeit nachträglich Belege anzuheften, müsste DATEV ergo Ihre Logik, welche Informationen festgeschrieben werden anpassen und die Möglichkeit schaffen, gewisse Informationen wie den Beleglink nachträglich zu bearbeiten.

Hier hängt voraussichtlich nicht nur sehr hoher Programmieraufwand von Seiten der DATEV an der Umsetzung, sondern auch die Notwendigkeit DATEV Rechnungswesen neu auf die GoBD-Konformität testieren zu lassen.

Das ist aber nur mein Versuch eine möglich realistische Einschätzung abzugeben, wie wahrscheinlich es ist, dass DATEV so eine Funktion nachliefern wird.

[#28]

@andreashausmann ,

dass festgeschriebene Buchungsstapel nicht einfach so 'nach Gutsherrenart' wieder zum Ändern zu Verfügung gestellt werden, halte ich auch für unwahrscheinlich.

Die Datev kann sich hier fest auf die GoBD berufen.

Aber ich kann immer noch nicht einsehen, dass ein Beleg, dessen Beleglink bereits im Buchungsstapel gespeichert ist, nicht auch noch nachträglich ausgetauscht oder ergänzt werden darf.

Ein Papierbeleg könnte doch nachträglich auch durch einen 'schöneren' Beleg ersetzt werden, wenn er z.B. durch Kaffee- oder Fettflecken oder durch bittere Tränen der Verzweiflung unleserlich geworden ist 😎.

Gibt es irgendwo eine Fundstelle im Gesetz, die das Austauschen von Digitalen Belegen verbietet, sofern sich an der Buchung nichts ändert ?

... also ist mein Vorschlag bzw. meine Idee:

bei (temporär) fehlenden Belegen sollte man einen 'Dummy'-Beleg generieren, ggfs. eine leere Seite, die aber rein technisch schon als Beleg zählt, der mit einem Buchungssatz mit Hilfe einer eindeutigen GUID verknüpft ist. Dieser 'Dummy-Beleg' könnte dann später ersetzt oder ergänzt werden 

.... so jedenfalls die/meine Theorie ... 😎

[#29]

Für @EricTempler1810 wäre es vielleicht ganz nett, wenn sich die Datev mal offiziell dazu äußern würde.

Wenn die Funktion nicht geplant ist, auch in den nächsten Monaten/Jahren nicht geplant werden wird, dann kann man das ja offen kommunizieren - zumal es auch Gründe geben mag, das nachträgliche anhängen oder austauschen nicht zuzulassen.

Technisch gesehen müsste man das ganze nur etwas erweitern:

Anstatt beim Buchungssatz die BelegID zu hinterlegen müsste man jeder Buchung eine feste ID geben.

Dann könnte man in einer Datentabelle der BuchungsID eine BelegID zuordnen.

Man könnte der BuchungsID dann auch mehrere BelegIDs zuordnen,

man könnte Belege für ungültig erklären, weitere Belege nachträglich hinzufügen,

die Zuordnungen natürlich mit einem Festschreibedatum versehen - also alle Änderungen nachvollziehbar und  GoBD konform.

@EricTempler1810 

Da ich auch nicht wirklich mit einer baldigen Lösung von Datev rechne, würde ich das Problem der großen Anzahl von nicht angehängten Belege lösen, indem ich einen "Schattenbestand" anlege.

Also alle festgeschriebenen Vorläufe exportieren, in diesen Vorläufen die nicht angehängten Belege anhängen.

Das Buchungsjahr in einem anderen Datenpfad neu eröffnen die Vorläufe importieren und festschreiben.

Das ganze Dokumentieren, beide Bestände 10 Jahre aufbewahren, ...

Dann würde ich mich auch trauen die Originale zu vernichten, denn das scheint ja eigentlich der Ausgangspunkt der Frage gewesen zu sein.

[#30]

Naja...

Das ist ja alles gut und schön, einige "Tipps und Tricks" waren dabei.

Das ist ja auch schön und gut, löst aber das Problem nicht...

Dieser Wunsch wurde nun schon einige male geäußert, eine IT-Technische Umsetzung ist definitiv möglich, nach GOBD sehe ich hier keine Probleme (korrigiert mich wenn ich falsch liegen sollte).

Also? Wo liegt das Problem? 

Ich brauche hier kein "Datev mach es halt einfach nicht", oder ein "Ich sehe keine Notwendigkeit". Wenn ich belehrt werden will gehe ich meine Großeltern besuchen *hust hust*.

Die Communitiy ist die einzige Schnittstelle zwischen DATEV und der Außenwelt/ Normalbürgern. Wir haben schon das ein oder andere mal etwas anstoßen können, also warum jetzt nicht? 

Denn anders kann es ja scheinbar nicht funktionieren!