Aufhebung der Festschreibung beim Import von Fremddaten

[#1]

Ich bin verwirrt. Datev hat eine für uns wichtige Funktion abgekündigt.

Wir bekommen von Mandanten CSV/Excel-Dateien und importieren diese in Kanzlei-RW.

Manche dieser Dateien enthalten falsche Werte oder die Beträge sind mit falschen Vorzeichen o.ä. erfasst.

Bisher haben wir diese Fehler beim Buchen korrigiert.

Nach August 2019, geht dies wohl nicht mehr. Das ist toll und behindert das Verbuchen von Mandantendaten.

Warum werden dann nicht gleich alle Buchungen in allen Vorläufen; ob Import  oder laufende Erfassung sofort festgeschrieben? Ist dies ein Rückschritt in das Zeitalter der 80er Jahre. Vielleicht verstehe ich das auch falsch? Kann mir jemand "aufs Pferd" helfen?

Heißt dass, das "perfekte" Buchungen in CSV/Excel vorliegen müssen, damit ich nicht alle Buchungen mit Generalumkehr erfassen und korrigieren muss?

Eventuell auch in Importdateien Konten/Gegenkonten, wenn der Mandant diese nicht vorkontiert?

Grüße aus dem Rheinland

Martin Heim

[#2]

Guten Morgen,

fehlerhafte Vorläufe werden meines Wissens weiterhin nicht festgeschrieben. Z.B. unvollständiger Buchungssatz oder Betrag mit negativen Vorzeichen (es gibt ihr aber auch die Möglichkeit negative Beträge zu importieren - nämlich wenn ich das S/H Kennzeichen an das Vorzeichen der Beträge "Koppel".

Vorläufe deren Festschreibekennzeichen "nicht festgeschrieben" lauten werden auch weiterhin nicht festgeschrieben.

Unbedingt ist jedoch zu beachten, dass ich den Daten-Export im Urzustand revisionssicher aufbewahre.

[#3]

Hallo Herr Heim,

ich gehe davon aus, dass es keine Schnapsidee von Datev ist, dass Buchungsstapel demnächst nur festgeschrieben importiert werden können, sondern eine gesetzliche Vorgabe.

Mir gefällt das auch üüüüüberhaupt nicht

Gruß

Michael Vogtsburger

P.S.

Ich vermute, dass ich dann evtl. gezwungen bin, Buchungsstapel mit einem externen Tool zu korrigieren

Nachtrag:

Ich hatte mich zu diesem Punkt (z.B. wg. den Selbstbuchern mit REWE Compact) auch schon etwas informiert und erinnere mich an folgende Aussage, die irgendwo stand:

Fehlerhafte Buchungssätze und z.B. nicht bebuchbare Konten etc. werden nicht importiert.

Es gibt ja schließlich auch Buchungsstapel, die mit Fremdsoftware erstellt bzw. exportiert wurden und die eine evtl. große Zahl fehlerhafter Buchungssätze enthalten könnten. Eine Massenändeung wäre dann wohl nicht mehr möglich, da es die fehlerhaften Buchungssätze nicht bis in die Primanota schaffen.

[#4]

Ich habe CSV Dateien, die neben Umsätzen auch Kosten enthalten. Die Position "Konto bzw. Gegenkonto" bei den Kosten wird vom Mandanten nicht gefüllt, so dass ich immer nacharbeiten muss. Das geht natürlich bei 500 bis 800 einzubuchenden Buchungsvorgängen in Datev einfacher/komfortabler als in Excel/CSV. Ab und an muss die Belegnummer geändert werden oder ein Steuersatz manuell erfasst werden. Die übermittelten Texte haben oft mit Umlauten Probleme etc.pp.

Ich habe absolut kein Verständnis dafür, dass ich in Excel schon den perfekten Buchungssatz herstellen muss.

Der Buchungssatz muss ja noch nicht einmal fehlerbehaftet sein. Er kann ja auch nur (versehentlich) falsche Texte oder Konto-Nr., etc. enthalten. Diese Sachen fallen dann beim Abstimmen auf. Und dann muss über Generalumkehr korrigiert werden.

Ich kann nicht erkennen, worin der Unterschied zwischen einer normalen Fibu-Buchung und 500 Buchungen am Stück besteht. Deshalb müsste als logische Konsequenz jede Buchung sofort festgeschrieben werden.

[#5]

Nachtrag:

Was ist mit Bankdaten, die als csv-Datei vom Mandanten übermittelt werden.

Insbesondere von Banken, die nicht an RZ-Bankinfo teilnehmen. z.B. N26 ?

[#6]

Ich rechne auch mit viel Ärger und zusätzlichem Aufwand mit "fremden" Buchungsstapeln.

Z.B. denke ich mit Grauen an die jährlich 'auftauchenden' 12 Buchungsstapel eines Mandanten mit zusammen ca 150.000 Buchungssätzen.

Wenn sich hier irgendwelche systematischen Buchungsfehler eingeschlichen haben, macht die Korrektur richtig viel Arbeit.

Es wäre mal interessant zu wissen, wie sich die Datev-Entwickler das Handling mit den zu importierenden und zu verarbeitenden Buchungsstapeln vorstellen.

.... bin gespannt ...

Viele Grüße

Michael Vogtsburger

[#7]

.... bin gespannt ...

Dann halten Sie die Spannung mal seeeehr lang aufrecht.

[#8]

Hallo,

also mir wurde gesagt, dass die Sätze nur festgeschrieben werden wenn keine Fehler oder Hinweise enthalten sind. Das bedeutet sobald ein Fehler enthalten ist schreibt das Programm den Stapel nicht automatisch fest.
LG

[#9]

Aber wie gesagt. Was ist mit den Fehlern die Datev nicht erkennt?

[#10]

Die Frage ist nur, ob fehlerhafte Buchungssätze überhaupt exportiert werden können (z.B. aus "Mittelstand Faktura und Rechnungswesen Compact")

Und was passiert mit einem Stapel, der fehlerhafte Buchungen enthält ?

Wird der Stapel dann  komplett abgelehnt oder filtert REWE die vermeintlich korrekten Buchungssätze heraus, "die Guten in´s Kröpfchen, die Schlechten in´s Töpfchen" (oder so ähnlich) ?

Und wie geht´s weiter mit den aussortierten Buchungssätzen ?

Soll man dann anhand eines Fehlerprotokolls alle fehlerhaften Buchungssätze manuell erfassen ?

Die Protokollierung des Importvorgangs empfinde ich sowieso nicht als ausreichend

Gibt es vielleicht jemanden, der hier keine Problem auf sich zukommen sieht ?

[#11]

Kleiner Tipp - falls Sie es nicht wussten: Beim Datev-Format befindet sich das Festschreibekennzeichen im Kopf der Datei in der Zelle U1. Dort muss eine 0 stehen. = Festschreibung: Nein

[#12]

Ich kenne das Datev-Format und den Aufbau der CSV-Dateien.

Es ist ja aus anderen Gründen immer mal erforderlich oder hilfreich, hier "einzuwirken".

Aber was nützt ein Festschreibekennzeichen ="0" wenn es nicht akzeptiert wird.

So wie es sich anhört, akzeptiert die kommende REWE-Version keine nicht festgeschriebenen Stapel bzw. die Stapel werden zwangsweise festgeschrieben.

[#13]

Verstehe ich das richtig?

Wenn ich den zu importierenden Buchungsstapel als DATEV-Format herstellen kann (und nicht als individuelle Liste) und in der Spalte U eine 0 steht, dann wird die Buchung nicht festgeschrieben.

Auch künftig?

[#14]

Dann lesen wir das unterschiedlich. Wenn bisher nix drin stand, wurde auch automatisch festgeschieben. Das konnte man Rückgängig machen - ging mE irgendwie über die Rechteverwaltung, also dass spezielle Nutzer das konnten. Das soll zukünftig nicht mehr gehen. Ich sehe dort nicht stehen, dass Vorläufe die mit dem Festschreibekennzeichen "Nein" eingespielt werden, auch zwangsweise Festgeschrieben werden. Damit würde das Kennzeichen ja auch überflüssig werden.

Aber: Ich will nicht behaupten, dass ich Recht habe. Ich lese das halt nur nicht so heraus.

Edit: @Herr Heim - so lese ich das heraus.

[#15]

Gibt es vielleicht jemanden, der hier keine Problem auf sich zukommen sieht ?

Gar keine Probleme vielleicht nicht, aber so viel ändert sich nun auch nicht und das Thema ist schon min. 2 Jahre alt.

Vorläufe mit Fehlern werden, wie bisher auch, mit Fehlern (rotes Ausrufezeichen) eingespielt (außer man entscheidet sich in der Auswahlmaske dagegen) und nicht festgeschrieben.

Das DATEV-Format enthält ansonsten eine Spalte in der entschieden wird, ob der Vorlauf festgeschrieben werden soll oder nicht. Bei aktuellen Fremdprogrammen sollte man also schon beim Export die Entscheidung treffen können und das Format ggf. entsprechend anpassen.

Die LODAS-Buchungen werden z.B. nicht festgeschrieben:

Bei Fremdprogrammen bei denen eine Anpassung des DATEV-Formates (oder ASCII) nicht vorgenommen werden kann, muss ggf. manuell eingegriffen werden und ein Fehler "provoziert" werden oder eine Spalte mit dem Festschreibekennzeichen manuell eingefügt werden.

Was die GoBD angeht, muss jeder für sich eine Entscheidung treffen, z.B. entsprechende Verfahrensdokumentationen. Aber das müsste man ggf. auch heute schon bei Fehlern aus Fremdprogrammen

EDIT: Mit "Spalte" meine ich das Festschreibekennzeichen wie von Herrn Kahl erläutert bzw. ich meine das bei ASCII Dateien, dass ganze auch mit einer eigenen Spalte gelöst werden kann.

[#16]

Darüber sind wir bei den 13.0B Pilot DVD auch gestolpert, wird direkt festgeschrieben. Das wird also definitiv kommen...

[#17]

Aussage auf der Datev-Website ("Aktuelles")

Buchungsstapel ohne Festschreibekennzeichen werden beim Import von ASCII-Daten in ein DATEV-Rechnungswesen-Programm generell automatisch festgeschrieben. Bisher kann diese Automatik mittels der Funktion Festschreibung aufheben beim Import oder bei der Stapelverarbeitung ausgeschaltet werden, sofern das entsprechende Ausnahmerecht in der Benutzer- und Rechteverwaltung eingerichtet ist.

Ab Installation der DATEV-Programme 13.0 entfällt dieses Ausnahmerecht. Die Festschreibung kann dann nicht mehr aufgehoben werden

.

@thomas kahl

Sie meinen also, man müsste nur eine Null setzen, dann wäre alles paletti ?

Wenn es so ist, hätte ich nichts dagegen, aber noch glaube ich nicht daran.

Es wäre zu simpel

[#18]

Ja, meine ich. Sowohl die Überschrift als auch der Text bezieht sich doch auf "Buchungsstapel ohne Festschreibekennzeichen". In meinem Fall steht doch Eines drin.

Aber Genaues kann da nur die Datev zu sagen.

[#19]

Ich kann nicht verstehen, dass Datev hier so 'schwammig' bzw. missverständlich formuliert.

Wäre es so viel Aufwand, die 3 Alternativen "ohne Festschreibekennzeichen", "mit Festschreibekennzeichen NEIN", "mit Festschreibekennzeichen JA" deutlich zu erklären, vor allem, da enormes Konfliktpotential darin steckt ?

Nachtrag:

.... und wofür braucht man eine Rechteverwaltung, wenn man in der CSV-Datei im Datev-Format mit einem schnellen Klick die Festschreibung nach wie vor und auch zukünftig aufheben kann ?

Falls diese Festschreibungs-'Logik' nur eine Datev-'Idee' ist und man sie so leicht aushebeln kann, soll es mir sehr recht sein.

Niemand ändert Buchungssätze ohne Not

Die Änderungen müssen natürlich "ordentlich" protokolliert werden (hallo GoBD)

[#20]

Moin,

ist Ihnen das Einlesen von ASCII-Daten als Buchungsvorschläge bekannt?

Wenn man Daten über diesen Punkt in Kanzlei-Rewe einliest, erhält man Buchungsvorschläge wie bei den Bankbuchungen und der Stapel ist selbstverständlich nicht festgeschrieben.

Viele Grüße,

B. Fitschen

[#21]

Hallo Herr Heim,

aufgrund der GoBD und den damit verbundenen strengeren Festschreiberegelungen wurden mit der Version 5.1 der DATEV Rechnungswesen-Programme (Januar 2016) das DATEV-Format und das aktuelle ASCII-Format für Buchungsstapel um ein Festschreibekennzeichen erweitert.
Mit diesem Kennzeichen wird gewährleistet, dass ein Buchungsstapel, welcher in einem DATEV Rechnungswesen-Programm oder dem Programm eines anderen Herstellers erfasst und festgeschrieben wurde auch nach dem Import in ein DATEV Rechnungwesen-Programm nicht mehr ohne weiteres verändert werden kann. Dies dient dem Prinzip der GoBD: der Durchgängigkeit und der Nachvollziehbarkeit.

Mit Einführung des Festschreibekennzeichens im Jahr 2016 wurde mit dem Ausnahmerecht für einen Übergangszeitraum die Möglichkeit geschaffen, die Festschreibung bei Buchungsstapeln mit Festschreibekennzeichen "Ja" (1) oder mit fehlendem Festschreibekennzeichen ("?") aufzuheben. Die Aufhebung der Festschreibung wird dabei protokolliert.

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.

Lediglich für Buchungsstapel ohne Festschreibekennzeichen ("?") wird, wie bereits zur Einführung des Festschreibekennzeichens im Jahr 2016 kommuniziert, mit Installation der DATEV Rechnungswesen-Programme 13.0 (Sommer 2019) das Ausnahmerecht entfallen. Hintergrund ist, dass bei Buchungsstapeln ohne Festschreibekennzeichen ("?") der Grundsatz der Durchgängigkeit und Nachvollziehbarkeit nicht gewährleistet werden kann.

Bitte prüfen Sie, ob die aktuelle Version des Fremdsystems installiert wurde. Für einen Übergangszeitraum seit Einführung des Festschreibekennzeichens im Januar 2016 bis Sommer 2019 sollten Anbieter von Fremdsystemen die Möglichkeit haben, die Schnittstelle entsprechend anzupassen.

Sollten Sie weiterhin Buchungsstapel ohne Festschreibekennzeichen erhalten und verarbeiten, kontaktieren Sie bitte den Hersteller des entsprechenden Programms. Möglicherweise steht bereits eine neue Programmversion zur Installation zur Installation bereit, welche den Festschreibestatus enthält.

Muss die Schnittstelle des Fremdsystems angepasst werden, finden SIe bzw. der Hersteller alle Informationen zur Einrichtung einer DATEV-Format-Schnittstelle unter www.datev.de/datev-format.

Weitere Informationen finden Sie im Informationsdokument 1080697.

Mit freundlichem Gruß

DATEV eG

Simone Jordan

Produktmanagement Rechnungswesen (FIBU)

[#22]

Hallo Frau Jordan,

danke für die Aufklärung.

Ich hatte schon befürchtet, dass diese Funktion ähnlich 'radikal' durchgesetzt wird wie die Abkündigung des Postversandformats.

Aber mit der oben beschriebenen Logik kann ich 'leben', ohne beim buchen zu fluchen

Viele Grüße

Michael Vogtsburger

[#23]

Sehr geehrter stefans,

Ihrem Beitrag kann ich nur zustimmen, dass Thema ist nicht neu!

Grundsätzlich ist es wünschenswert, dass Daten aus Fremdsystemen 1:1 ohne Anpassungsmöglichkeiten übernommen werden. Falls dies bei Einzelfällen zu Problemen bei der laufenden Bearbeitung führt, sind zwei Tools der DATEV empfehlenswert:

1. Nutzung der Bearbeitungsfunktion von festgeschriebenen Stapeln über die Primanota. Die Funktion ist in folgendem Beitrag erläutert:
Wunsch: Funktionen von Primanota-Buchungen bearbeiten verbessern

2. Man kann auch Vorläufe direkt als Buchungsvorschläge einspielen, dadurch umgeht man das Thema komplett und kann auch noch mit Lerndateien arbeiten.(Edit: Dies hat auch Frau Fitschen bereits erläutert!)

Beide Ansätze sind GoBD-technisch schöner abzubilden, als wenn die originären Daten auf Fehler laufen und diese in DATEV im gleichen Vorlauf korrigiert werden. Sobald die Korrekturen über einen eigenen Buchungsstapel erfolgen, ist das Ausbessern der Fehler manuell aufwändiger als die Nutzung der beiden angesprochenen Möglichkeiten...

MfG

Tobias Ettl

[#24]

Sehr geehrte Frau Jordan,

wie erfasse ich ein Festschreibungskennzeichen bei einer Datei, die nicht aus einem "Fremdsystem", sondern aus einer Excel-Liste kommt?

[#25]

Hallo Herr Heim,

wenn Sie mit Excel-Listen arbeiten, könnte das Datev-Tool "EBS-Konvertierung" ganz nützlich sein.

Das Tool macht aus einer Excel-Liste (Excel-Tabelle) einen 'fertigen' und importierbaren Buchungsstapel im Datev-Format

Viele Grüße

Michael Vogtsburger

[#26]

Danke für den Hinweis,

die Übernahme der Daten aus Excel hat bisher immer mit der individuellen "Formatierung" der Dateien gut funktioniert.

Wenn aber nur dadurch (DATEV-Format) das Festschreiben verhindert werden kann, wende ich es gerne an.

[#27 · Accepted solution]

Guten Morgen,

dass geht auch weiterhin meinem Verständnis nach.

Frau Jordan schreibt, dass die Export Datei ein Festschreibekennzeichen haben soll/muss. Von einem festen Format ist nicht die Rede. Das heißt doch, dass ich auch weiterhin Excel/CSV Dateien bearbeiten kann und hier lediglich eine Spalte mit dem Festschreibekennzeichen 0= Nein oder 1= Ja einfügen muss.

VG

[#28]

Hallo Herr Heim,

die Lösung von Herrn Vogtsburger ist aus meiner Sicht zwar möglich, aber zu umständlich.

Beim ASCII-Import vermeiden Sie die Festschreibung wir folgt:

In der zu importierenden ASCII-Datei sollte eine weitere Spalte enthalten sein in welcher zu jedem Datensatz eine „0“ enthalten ist. Dieser Spalte ordnen Sie den Inhalt „Festschreibung“ (steht bei der Spaltenzuordnung meine ich unter Stapelinformationen) und das war es.

Damit wird beim Import heute und auch in Zukunft nichts festgeschrieben.

Viel Erfolg

[#29]

OK,

ich habe jetzt gesehen, dass man im Datensatz unter Stapelverarbeitung ein Feld anlegen kann mit der Feststellungsziffer.

Danke. Jetzt ist meine Frage vollständig beantwortet. So 100%ig konnte ich das aus den Erläuterungen von Frau Jordan nicht herauslesen. Danke für die "Praktiker"-Anwort..

Mit freundlichen Grüßen

Martin Heim