Hallo liebe DATEV-Gemeinschaft,
unlängst wurde mit der Programm-DVD 13.00 angekündigt nun auch die letzte Möglichkeit abzuschalten um Buchungsstapel beim Import noch nicht festzuschreiben. Über die Sinnlosigkeit der GoBD möchte ich hier nicht diskutieren. Die DATEV bietet jedoch in Info-Dokument 1070379 nur drei Wege zum GU-Storno der dann festgeschriebenen Buchungssätze an.
Stornieren einzelner Buchungen über das Kontoblatt (ohne Mehrfachauswahl)
Stornieren über die Primanota
Stornieren ganzer Stapel
Meiner Meinung nach gehen alle Szenarien mehr oder weniger an der Praxis direkt vorbei. Die einzige brauchbare und handhabbare Variante wäre meiner Meinung nach das Stornieren über das Kontoblatt mit der Möglichkeit mehrerer selektierter (vermeidlich falscher) Buchungen. Man bedenke, dass komplette Umbuchungen von Konten von A nach B nach Festschreibung nur unter erheblichem Zeitaufwand möglich sein würden (Thema E-Bilanz Notwendigkeiten usw).
Das Storno über die Primanota bringt keinen Mehrwert, da meistens die Buchungen verteilt über mehrere Erfassungszeiträume liegen und das erneute Aufrufen einer anderen Primanota nur Zeit kostet ähnlich wie die Einzelauswahl aus dem Fibu-Konto
Das Storno eines ganzen Stapels ist wohl eher selten, kann aber bei komplett fehlgeschlagenen Importen von mir aus noch sinnvoll sein. Hier wäre meiner Meinung nach ein Zusatzangebot notwendig, welches eine Vorabprüfung der zu importierenden Daten anbietet und eine "Verbuchung auf Probe" durchführt. Nur so lassen sich vor dem Import Fehler aufspüren und ohne Kollateralschäden an der Buchführung ggf. noch vermeiden. Wir werden damit rechnen müssen dass das Produkt Buchhaltung welches unsere Kanzleien anbieten zu einem Flickenteppich verkommt welches wohl mit einer ästhetischen und anschaulichen Buchführung nichts mehr zu tun hat. Dafür kann primär die DATEV nichts, da die GobD dies vorschreiben, jedoch werden wir ab 13.0 mehr funktionale Untersützung seitens (Kanzlei)-Rechnungswesen brauchen. Mich würde interessieren wie ihr das seht und was die DATEV hier noch plant.
Wir haben bereits 10-20 mal diesen Verbesserungsvorschlag eingereicht. Ich würde gerne durch Feedback eurerseits hier mehr Druck auf die notwendigen Anpassungen bekommen.
Vielen lieben Dank!
Christian
Hallo Herr Ziegler,
die Änderungen bei der Festschreibung beim Datenimport betreffen nur Datensätze die kein Festschreibekennzeichen enthalten. Sofern ein Festschreibekennzeichen übergeben wird ändert sich nichts. Siehe u. a. hier:
Hallo Herr Sawatzki,
ich verstehe die Ankündigung wörtlich. Dort heißt es ".... werden generell festgeschrieben". Ich befürchte dass sich das mit dem Kennzeichen dort dann erledigt hat, dies wäre die bisherige Praxis mit Ablaufplan. Hoffnung macht es mir aber dennoch, wenn ich lese, dass Stapel ggf. mit fehlerhaften Buchungen die Festschreibung dann aussetzen lassen. Sonst wäre eine Nachkontrolle faktisch unmöglich.
Meine Diskussion sollte sich aber primär darauf beziehen, dass ich fehlende Programmfunktionen mit der Problematik der nachträglichen Korrektur vermisse. Wie stehen Sie zu meinem Vorschlag ?
Hallo Herr Ziegler,
sofern es sich um zu berichtigende Buchungen einer Periode handelt stimme ich Ihnen zu, dass eine im Belege buchen (z. B. in der Kontoblattansicht) mögliche Mehrfachkorrekturmöglichkeit fehlt.
Im Kontoblatt selber vermisse ich diese Funktion nicht. Dies mag von meiner individuellen Arbeitsweise abhängen.
Ein Storno hat aus meiner Sicht in der Periode und mit dem Datum zu erfolgen, zu dem die ursprüngliche Einbuchung erfolgte. Wenn dann im Kontoblatt Buchungen unterschiedlicher Perioden ausgewählt werden würden, müsste sich das Belege buchen zur Korrektur mehrfach öffnen. Das wäre mir zu unübersichtlich.
Mir reicht bisher die Möglichkeit der Korrektur in der Primanota oder ich erledige betroffene Fälle gleich per Kontenüberleitung beim Import.
Sehr geehrter Herr Ziegler,
ich sehe das ebenso wie Sie recht kritisch.
Da wir leider immer noch viele Daten über ASCII Import übernehmen (die ja gerade kein Import Kennzeichen haben)
Bei einigen Mandanten wird nachträglich nur z.B. die KOST hinterlegt. Hierfür den ganzen Stapel zu stornieren und neu zu erstellen ist zwar problemlos möglich aber gefühlt überflüssig.
Gerade aber beim Erstellen des ASCII Importes bzw. beim testen der EBS Konvertierung sehe ich das als Kritisch an. Zukünftig muss dies dann wohl erst über den Mustermandanten getestet werden bevor es dann in den Mandanten importiert wird.
Oder so wie es wahrscheinlich bedingt durch die GobD "vorgegeben" ist
Einspielen - festschreiben - kontrollieren - Generalumkehr - korrigierte Buchung.
Die Daten dürfen ja nicht verändert werden
§ 146 (4) AO
Gerade aber beim Erstellen des ASCII Importes bzw. beim testen der EBS Konvertierung sehe ich das als Kritisch an. Zukünftig muss dies dann wohl erst über den Mustermandanten getestet werden bevor es dann in den Mandanten importiert wird.
Moin,
wenn Sie mit der aktuellen Version der EBS-Konvertierung arbeiten bzw. die ASCII-Import-Beschreibungen auf die neuen Versionen umgesetzt haben, haben die einzulesenden Daten ein Festschreibekennzeichen.
Und wenn dieses Festschreibekennzeichen auf "nicht festschreiben" steht, können Sie die Daten nicht festgeschrieben übernehmen und "ganz normal" im Programm prüfen. Das Festschreiben erfolgt dann hinterher in gewohnter Weise (im Regelfall vermutlich bei Übermittlung der Umsatzsteuer-Voranmeldung).
Das automatische Festschreiben betrifft nur Importdateien, die kein Festschreibekennzeichen haben. Diese Dateien stammen meistens aus Fremdprogrammen (des Mandanten). Dort müsste ggf. die Importbeschreibung angepasst werden, damit auch diese Daten (weiterhin) im nicht festgeschriebenen Zustand übernommen werden können.
Viele Grüße
Uwe Lutz
Hallo Herr Lutz,
ich denke dass dies die momentane Praxis abbildet. Es wird aber in dem Info-Dokument und in den Abkündigungen von einer generellen Festschreibepflicht gesprochen. Ich denke nicht dass die Anlieferung ohne Festschreibekennzeichen dann noch geht.
Da haben Sie recht, ich würde dann auch davon ausgehen, dass entsprechend der Selektion auch die dazugehörigen periodischen Stapel angelegt werden welche den Buchungen zuzuordnen sind.
Haben Sie den o.g. Thread schon gelesen (Aufhebung der Festschreibung beim Import von Fremddaten )?
Ich war ebenso wie Sie der Meinung, dass es zukünftig einen generellen Festschreibungszwang geben wird.
Aber dem ist offenbar nicht so.
Viele Grüße
Michael Vogtsburger
Hallo Herr Ziegler,
helfen Sie mir einmal: In welchem Dokument ist davon die Rede, dass ALLE importierten Stapel generell festgeschrieben werden? Ich kann eine derartige Information nirgends finden.
Bisher war immer nur die Rede davon, dass Stapel, die KEIN Festschreibekennzeichen haben, künftig automatisch festgeschrieben werden.
Bei allen anderen Stapeln wird über das Festschreibekennzeichen "Ja/Nein" geregelt, ob eine Festschreibung beim Import erfolgt.
Viele Grüße
Uwe Lutz
Hallo Herr Lutz,
ja, Frau simone.jordan , hat im o.g. Thread den Sachverhalt gut erklärt
Die Möglichkeit die Festschreibung beim Import von Buchungsstapeln mit Festschreibekennzeichen "Ja" (1) aufzuheben bleibt weiterhin bestehen.
Buchungsstapel mit Festschreibekennzeichen "Nein" (0) werden beim Import nicht festgeschrieben und können nach der Verarbeitung in den DATEV Rechnungswesen-Programmen weiterhin bearbeitet werden.
Ich selbst hatte die ursprüngliche 'spartanische' Formulierung auch missverstanden.
Viele Grüße
Michael Vogtsburger
Die Diskussion, ob ein vorher manuell in Excel bearbeiteter Stapel beim Importieren sofort festgeschrieben werden muß, oder nicht, ist doch ein Wirtz.
Wenn irgend eine Vorschrift dieses Programmverhalten fordern sollte, dann würde ich mir dringendst wünschen, daß es eine "Rückgängig machen"- Möglichkeit gibt, die den Import komplett entsorgt und auch das Akrivitätenprotokoll zurück setzt. Das funktioniert natürlich nur, solange keine weiteren Aktionen mit dem Stapel geschehen sind, wie Senden, Ausziffern, usw.
Im Prinzip wünsche ich mir, daß der Anwender die Buchhaltung mit einem Mausklick auf den Stand vor dem Import rücksichern kann.
Alternativ: Beim Import kommt eine Warnmeldung, die den Anwender darauf hinweist, daß der zu importierende Stapel ohne Kontrollmöglichkeit sofort festgeschrieben wird. Damit kann der Anwender die Spalte "Festschreibekennziffer" in Excel nochmals überprüfen und korrigieren. - Welch ein Wahnsinn …
Nein, ich möchte Importieren, das Ergebnis sichten, und dann entscheiden, ob der Import korrekt war. Wenn ja, dann bitte festschreiben, wenn nein (Verkehrter Mandant, verkehrte Periode, usw.), dann wird alle komplett raus gekickt.
Ich habe hier eine BH, wo das Fremdsystem jeden Monat mit neuen tollen Ideen zur Spaltenstruktur aufwartet (Updates), so daß regelmäßig der Import komplett weg muß, um einen zweiten Versuch zu starten. PS. Versandhandel, wo bei Doppeltbuchungen das ausziffern per Auftragsnummer Amok laufen würde.
PS: zu 95 % aller Fälle kommt es heute vor, daß wenn beim Import das [ x ] zum Aufheben gesetzt wird, der Import nach der Kontrolle doch ohne jede Änderung gesendet wird. Da würde ich mir natürlich einen anderen Eintrag im Aktivitätenprotokoll wünschen, denn der Vorlauf wurde doch ohne Änderung festgeschrieben.
Ich war jedenfalls auch schon überflüssigerweise in Panik wegen der vermeintlich zukünftig erzwungenen Festschreibung beim Importieren aller Buchungsstapel.
Dass das zukünftige Rewe-Import-Verhalten doch wesentlich harmloser ist als befürchtet, hat meinen Blutdruck wieder auf Normalwert gesenkt. Der Ärger wegen der Abkündigung des Postversandformats ist mir nämlich noch gut in Erinnerung. Mir ist bis heute immer noch nicht klar, warum die Datev diese Abwärtskompatibilität trotz aller Widerstände und Gegenargumente entfernt hat.
Ich werde mir mal einen Workaround 'stricken' (müssen), um die Import- und Änderungsaktionen mit 'fremden' Buchungsstapeln 'wasserdicht' dokumentieren zu können. Ich will gewappnet sein, wenn es zu Diskussionen bei Betriebsprüfungen kommen sollte.
Früher war alles sooo einfach...
Man bekam die Daten mit dem Herkunftszeichen "SV"
Jedes Ändern des Buchungssatzes machte ein "RE" daraus.
Heute...
Ich importiere den Stapel aus dem DATEV- Vorsystem: "RE" , im Protokoll stehe ich als Verfasser von "heute" drinnen.
Nachträglich ist es aus dem System nicht möglich, zu erkennen, welcher Buchungssatz Original ist, bzw. wo die Buchhaltung korrigieren mußte.
Wunsch:
Bei "bösen Stapeln" wird auf das Altbewährte zurück gegriffen und wieder das Kennzeichen "SV" eingeführt, anstatt den Stapel zwangs- festzuschreiben.
Wenn dieser Stapel dann gesendet wurde, sollte das "SV" doch in Zusammenhang mit dem Aktivitätsprotokoll ausreichend Beweis sein, daß in Rewe keine Änderung des Stapels erfolgte.
Ich werde mir mal einen Workaround 'stricken' (müssen), um die Import- und Änderungsaktionen mit 'fremden' Buchungsstapeln 'wasserdicht' dokumentieren zu können. Ich will gewappnet sein, wenn es zu Diskussionen bei Betriebsprüfungen kommen sollte.
Ich hatte mich ja auch schon "geoutet", dass ich "nacharbeite" s.
https://www.datev-community.de/message/104055?et=watches.email.thread#104055Re: KR Leistungsdatum - Übernahme Vorlauf von Mdt.
Ich bekomme vom Mdt. BWA, Susa, Opos, USt zum Abgleich. Diese lege ich in der DMS ab.
Der Mdt. bekommt von mir schriftlich, was ich geändert habe z.B. welche Kostenstelle ich ergänzt habe, oder ob ich direkt Konten geändert habe (z.B. Werkzeuge statt GWG) oder Vorsteuerschüssel ergänzt habe? Es sind nicht so viele Änderungen, von daher handhabe ich es derzeit so. Dazu hefte ich Belege hinter.
Aber wenn ich noch mehr machen muss...?
Wie ist Ihr Workaround aufgebaut?
Nach Update auf die 13.0 hat sich in dieser Richtung bei uns nichts verändert.
Die Festschreibung kann anscheinend also derzeit weiterhin aufgehoben werden.
Zu wann wird dies dann jetzt endgültig abgeklemmt?
MFG
Lathwesen
Hallo Herr Lathwesen,
das Sonderrecht besteht weiterhin. Die Änderung der aktuellen Programmversion besteht darin, dass dieses Sonderrecht nicht für Importdaten ohne Angaben zur Festschreibung gilt.
Viele Grüße
Christian Wielgoß
Nachdem der Beitrag sich doch etwas vergaloppiert hat wollte ich noch einmal drauf hinweisen um was es mir ging:
Dass die Festschreibung gesetzliche Pflicht ist, ist so, nicht schön nicht praktisch aber es ist so. Mir ging es s.o. darum mehr Unterstützung in der Bearbeitung der festgeschriebenen Buchungssätze zu erhalten. Also mehr Funktionalität um dann effizient und rechts sicher zu buchen. Das Storno über Kontoblätter oder eine Multi-Selektion von fehlerhaften Buchungssätzen wäre ein sehr großer und auch komfortabler Schritt in die richtige Richtung.
Eine Manipulation der Stapel sehe ich ebenso kritisch, wie auch die Tatsache dass wir aufgrund der Festschreibung mit einer optischen Informationsflut fehlerhafter Buchungen überschüttet werden (die man auch mit Option ausblenden kann).
Dennoch hat das wohl mit einem ästhetischen Buchen und einem ordentlichen Produkt jenseits dem Generalverdacht der Steuerhinterziehung, den ja jeder Mensch bei jedem Buchungssatz unterstellt wird - nichts mehr zu tun.
Hallo Herr Ziegler,
die Stornierung mehrere Buchungen eines Stapels ist bei festgeschriebenen Buchungen in der Primanota möglich.
Markieren Sie einfach die gewünschten Buchungen, öffnen das Kontextmenü und wählen „Buchungen bearbeiten“.
Welche "gesetzliche Pflicht" bezüglich Festschreibens besteht denn?
Wo ist geregelt, daß nach einem Import der Mitarbeiter diesen Import nicht komplett rückgängig machen darf, wenn er feststellt, daß es beim Import einen technischen Fehler gab?
Die DSGVO verbietet, daß mandatsfremde Daten eingespielt werden. Was nun, wenn der Import beim verkehrten Mandanten eingelesen wurde?
Bitte abändern, so daß ein Löschen des kompletten Vorlaufes so lange möglich ist, wie noch keine Folgeverarbeitung, wie DFÜ, Drucken oder ähnliches durchgeführt wurde.
Löschen so weit, daß selbst die Aktivitäten aufgeräumt werden, so daß der verkehrte import nie passiert ist.
§ 146 Abs. 4 AO
(4) Eine Buchung oder eine Aufzeichnung darf nicht in einer Weise verändert werden, dass der ursprüngliche Inhalt nicht mehr feststellbar ist. Auch solche Veränderungen dürfen nicht vorgenommen werden, deren Beschaffenheit es ungewiss lässt, ob sie ursprünglich oder erst später gemacht worden sind.
Diese Funktion ist einfach nur Dreck!!!
Ein Stornierung aus der Primanota ist nur in den gleichen Zeitraum möglich. Möchte ich lediglich ohne steuerliche Auswirkung, von Kto. 4970 auf 4980 umbuchen, kann ich das weder in einem offenen noch in einem neuen Vorlauf im aktuellen Buchungszeitraum machen.
Diese Funktion ist vielleicht hilfreich für die Stornierung eines kompletten Vorlaufes, aber einzelne Buchungen ist es unbrauchbar.
Gruß A. Martens
Hallo Herr Martens,
die von Herrn Sawatzki geschilderte Vorgehensweise eignet sich insbesondere für die massenhafte Korrektur von Buchungssätzen (Fallbeispiel des Herrn Ziegler).
Wenn es um einzelne Buchungen geht, dürfte die klassische Stornierung mit Generalumkehr weiterhin das Mittel der ersten Wahl sein.
Viele Grüße
Christian Wielgoß
Sehe ich auch so, es ist aber enttäuschend von DATEV, warum immer die zwangsweise Vorgabe des Buchungsstapelzeitraumes erzwungen wird. Zumal ein nachträgliches ändern des des Vorlaufzeitraumes wieder ein DATEV-Konform extremst umständlich ist.
Wann ist eine Buchung denn eine Buchung?
Darf ein Mitarbeiter nicht selber kontrollieren, ob er ein Einspielen einer Buchung nicht aufgrund eines technischen Fehlers ungeschehen machen muß?
Für mich ist eine eingespielte Buchung erst dann eine Buchung nach § 146 Abs. 4 AO, wenn das Einspielen korrekt erfolgte und diese im Nachfolgesystem "verarbeitet" wird, also konkret eine USZ- VA ausgelöst wird.
Dann gibt es natürlich auch Buchungen aus Vorerfassungs- Systemen oder selber zusammengebastelte Vorläufe, da ein Copy & Paste bei DATEV aus unterschiedlichen Jahren bzw. Mandanten nicht möglich ist.
Vielleicht dient die Buchführung, wo Vorläufe importiert werden nur internen Berechnungen? z.B. eine Konsolidierung mehrerer Firmen, um Statistiken zu führen (Problem; abweichende Rechnungswesens-- Zwecke bzw. Stichtage)
Warum gibt es überhaupt die Aufhebungsfunktion, wenn sie jetzt nur mit dem Festschreibe-Kz "Ja" funktioniert und die Aufhebung protokolliert wird?
Wer oder was hindert mich daran, das Festschreibe-Kz in der Datei auf "Nein" zu ändern und dann wird der Stapel normal ohne Festschreibung verarbeitet? Das muss ich jetzt sowieso bei vielen machen, da wir viele Dateien ohne Festschreibe-Kz bekommen ("?") und die Stapel zwingend nachbearbeitet werden müssen.
Hallo Alexander S.,
eben aus diesem Grund, damit Sie als festgeschrieben geltende Importdaten bei Bedarf als nicht festgeschriebene Buchungsstapel übernehmen können.
Viele Grüße
Christian Wielgoß
Wie gesagt, niemand hindert mich daran, die Datei zu öffnen und das Festschreibe-Kz zu ändern. Das ist nur ein Wert in der csv-Datei.
Hallo,
das ist mir schon bekannt, geht aber in der Arbeit an der Praxis vorbei. Ich suche mir meine Fehler meistens nicht in der Primanota zusammen, sondern beim Abstimmen der Konten.