Thema "Re: GdOB i.V.m. ASCII-Import" in Betriebliches Rechnungswesen

GdOB i.V.m. ASCII-Import

lupofresh — Thu, 23 Jun 2016 14:02:43 GMT

Hallo,

bei den ganzen Diskussionen etc. zum Thema "Festschreibung von Buchungsstapeln" und "Import von Postversanddaten/Buchungsdaten Datev-Format" habe ich den Eindruck gewonnen, dass ich zukünftig keine manuellen ASCII-Daten mehr einspielen kann. Vielleicht liege ich aber auch falsch.

Der Sachverhalt wäre der folgende:

- Der Mandant sendet mir eine Excel-Tabelle mit diversen Informationen.

- Diese Tabelle wird leicht angepasst um z.B. Konto und Gegenkonto sowie "Zusatzinformationen"

- Diese Tabelle wird anschließend im CSV-Format gespeichert und über ein individuelles ASCII-Format in Rewe eingespielt.

Werde ich jetzt zukünftig Probleme mit dem einspielen haben? Irgendwie ist bei dem Thema bei mir etwas "Hick-Hack" im Kopf.

Muss ich auch diese Daten zukünftig "sofort Festschreiben"? Dies würde ich gerne unterbinden, da unter Umständen mal bei der Tabellenbearbeitung etwas nicht korrekt läuft und einige Buchungen auf "Fehler" laufen. Es handelt sich hier schon um eine recht komplexe Sache, wo ca. 4.000 Kleinstbuchungen pro Monat übernommen werden.

LG Lupofresh

Re: GdOB i.V.m. ASCII-Import

theo — Fri, 24 Jun 2016 04:52:01 GMT

Werde ich jetzt zukünftig Probleme mit dem einspielen haben?

Nein.

Muss ich auch diese Daten zukünftig "sofort Festschreiben"?

Das ist (bis die Gerichte gesprochen haben) sicher 'Ansichtssache'. Die Datev ist der Meinung ja u. macht das automatisch. Aushebelung ist über die Nutzungskontrolle möglich.

In Ihrem Fall ist die Festschreibung m.E. an der Stelle quatsch, Sie haben die Daten des Mand. ja bereits 'zu Ihren Gunsten' verändert. (Unveränderlich) aufbewahren gem. GoBD würde ich die Datei, die sie vom Mand. erhalten.

Re: GdOB i.V.m. ASCII-Import

mkinzler — Fri, 24 Jun 2016 06:31:12 GMT

Wenn man sich ein eigenes ASCII-Format erstellt, kann man dort auch ein Feld für die Festschreibung festlegen und dieses mit 0 belegen.

Re: GdOB i.V.m. ASCII-Import

andreashofmeister — Fri, 24 Jun 2016 06:43:46 GMT

Cool.

Frage: und es wird nicht festgeschrieben, bzw. nicht gefragt, ob man festschreiben will? Ich nehme an, die Antwort lautet "JA"?!

Ok. Ab 1.1.2017 wird dieses eigene ASCII-Format auch noch unterstützt und es erfolgt dann keine (wie angekündigt) Festschreibung?

Dürfte von Interesse sein. Denn dann könnten man sich doch eigene Format bauen und wäre aus der Nummer aus...

Oder?

Re: GdOB i.V.m. ASCII-Import

Marco_Lachmann — Thu, 30 Jun 2016 07:23:47 GMT

Hallo Herr Hofmeister,

wenn ein Stapel im Vorsystem zum Zeitpunkt des Exports nicht festgeschrieben war und dieser mit dem entsprechenden Festschreibekennzeichen kommt, wird dieser auch zukünftig beim Import nicht festgeschrieben.

Mehr dazu: Schnittstellen in den DATEV pro-Rechnungswesen-Programmen aufgrund GoBD geändert

Mit freundlichen Grüßen

Marco Lachmann

Service Rechnungswesen (FIBU)

DATEV eG

Re: GdOB i.V.m. ASCII-Import

uwes — Thu, 24 Nov 2016 03:07:46 GMT

Hallo Herr Lachmann,

leider ereilt uns auch dieses leidige Thema. Ich muss meinen Frust echt mal zum Ausdruck bringen, dass man uns hier in der Entscheidungsfreiheit, seitens Datev derart beschneidet. Ich habe jetzt bei einigen Betriebsprüfern das Thema angesprochen. Nicht bei einem Betriebsprüfer war das ein Thema. Ganz im Gegenteil - die meisten versicherten mir, dass das intern derzeit noch nichtmal bekannt sei, darauf zu prüfen. Vielmehr würde natürlich Probleme geben, wenn die komplette Buchhaltung Anlass zur Beanstandung hätte. Ich spiele bei einem Kunden ca. 70.000 bis 100.000 Datensätze ein, die aus von mir handgefertigten Schnittstellen kommen, wie Paypal etc. Da genau diese Firmen oft Trennkennzeichen in normalen Texten haben oder auch Nullwerte übertragen, kommt es hin- und wieder zu Fehlern, die wir manuell nacharbeiten. Außerdem wollen wir pro Monat einen Buchungsstapel und nicht 15 Buchungsstapel, nur weil wir öfters einspielen. Nerv !!!!

Nun gut - aktuell haben wir alles über die NUKO ausgeschalten. Damit kann ich leben.

Wie gehts jetzt weiter - habe mir mal das Dokument angesehen.

Frage 1:

In 2017 kann ich nachwievor noch über NUKO diesen Quatsch aufheben - RICHTIG ?

Frage 2:

in meinen csv-Importen reicht mir also, wenn ich das Feldkennzeichen Feschreibung einfüge und in jeder Buchungszeile eine "0" eintrage - RICHTIG ?

Frage 2a: Herkunft-Kz kann ich mir also sparen ?

Frage 2b: Was passiert wenn bei einem Satz etwas anderes als Null drin steht, also eine "1"

Frage 3; Wird es dann ab 2018 so sein, dass wenn ich einen laufenden Buchungsstapel habe und in diesen einen Import aus einem Fremdsystem mache, dann dieser Buchungsstapel einfach geschlossen wird ???? Oder bleibt ein vorhandener offener Buchungsstapel auch immer weiterhin offen. Dann wäre mein Problem schon gelöst, andernfalls grenzt das Ganze an eine Katastrophe.

Es wäre schön, wenn Sie die Detailfragen noch klären könnten. Dann werde ich das halt mal anpassen. Ist wohl weniger aufwendig als die ganze Software zu wechseln, was ich schon in Erwägung gezogen habe.

Anregung an Datev:

Lasst das mit der Aufhebung in der NUKO. Wo soll der Schaden sein ??? Der Nutzer hat es gewollt und mit Dokumentationskennzeichen seitens Datev für sich so entschieden. Jeder sieht es und übernimmt die Verantwortung.

Dass man nur geschlossene Monate zur Umsatzsteuer senden kann finde ich auch unglücklich, aber gut, das ist zumindest irgendwo nachvollziehbar und diskussionswürdig. Das mit den Stapeln ist für mich von einem Theoretiker designt worden. Vermutlich kam der Gute noch nie über eine Buchhaltung mit 100 Buchungen hinaus. Sorry. Irgendwo muss ich grad den Frust abladen.

UweS

Re: GdOB i.V.m. ASCII-Import

mkolberg — Thu, 24 Nov 2016 05:27:58 GMT

Könnte bitte geprüft werden, ob es nicht möglich ist, einen eingelesenen Stapel einfach wieder zu löschen, wenn zwischenzeitlich keine steuerrelevanten Dinge passiert sind?

Praxisfall:

Mandant schickt aus seinem System einen Buchungsstapel, der üblicherweise problemlos einzuspielen ist. Durch eine Panne enthält der Stapel verkehrte Daten, oder es wurde versehentlich der Vormonat nochmals exportiert (nobody is perfect).

In der Kanzlei wäre nun folgender Ablauf denkbar:

- Mitarbeiter spielt den Vorlauf ein (incl. Festschreibe- Infos)

- Mitarbeiter sichtet die Buchhaltung und entscheidet:

-- Vorlauf OK -> Senden -> OK

-- Massive Fehler -> Vorlauf komplett entsorgen

Jetzt kann der Mitarbeiter weitere Aktionen unternehmen, wie:

- Vom Mandanten einen korrekten Stapel anfordern
- Vorlauf erneut einlesen und per NuKo Recht Fehler selber korrigieren.

Bitte beachten:

"Der Vorlauf muß zeitnah zum Senden festgeschrieben sein".

bedeutet:

vor dem Senden spricht nichts dagegen per "Rückgängig" das Einspielen des Vorlaufes zu stornieren. (Der Mitarbeiter hätte sich ja die Daten auch vorher ansehen können, um dann auf das Einspielen zu verzichten.) Das Stornieren des Einspielens muß natürlich auch den Vorlaufdaten wieder den Status: "nicht importiert" geben.

Re: GdOB i.V.m. ASCII-Import

mkinzler — Thu, 24 Nov 2016 07:31:35 GMT

Das würde der GoBD widersprechen. In diesem Fall muss man den Vorlauf per Generalumkehr "stonieren", den korrekten Vorlauf anfordern und neu einspielen.

Re: GdOB i.V.m. ASCII-Import

mkolberg — Thu, 24 Nov 2016 08:11:28 GMT

Ein Stornieren und neu Einspielen macht die Buchhaltung unübersichtlich und es gibt Situationen, wo der soeben importierte Vorlauf einfach wieder raus muß. (verkehrter SKR, verkehrter Zeichensatz, falsche Abrechnungsperiode, verkehrter Mandant, usw.)

Es muß doch eine GoBD- konforme Möglichkeit geben, daß der normale Anwender einen unverbindlichen Blick in die Postversanddaten werfen kann, bevor er diese endgültig in einer Buchhaltung mit automatischer Festschreibung importiert.

Wenn ein Vorlauf importiert- und sofort wieder entsorgt wird, haben wir doch den identischen Datenbestand, als wenn dieser Vorlauf nie importiert gewesen wäre.

Das wäre bei weitem besser, als wenn der Anwender erst mit NuKo- Recht sagt. "Ohne Festschreibung", um ihn dann doch festzuschreiben, wenn der Import wunschgemäß klappte.

Re: GdOB i.V.m. ASCII-Import

mkinzler — Thu, 24 Nov 2016 08:19:05 GMT

In der Zeit vor dem EDV-Einsatz durfte man Buchungen nur so streichen, dass der ursprüngliche Inhalt sichtbar bleibt. Dies soll im gewissen Umfung durch die GoBD wieder eingeführt werden. Der große Unterschied zu den vorherigen Bestimmungen ist auch die Ausweitung der Dokumentationskette/Prüfung vom Steuerberater ( als letztes Glied) auf die Vorsystemen betont wird.

Re: GdOB i.V.m. ASCII-Import

mkolberg — Thu, 24 Nov 2016 08:54:33 GMT

Hier geht es nicht um die üblichen Fehlbuchungen, sondern es muß ein Weg gefunden werden um Fehler, die bei der technischen Übertragung von Daten von einem System auf das andere System entstehen können, zu eliminieren.

Gerade beim EDV- Einsatz muß eine Integrität der Daten sichergestellt werden, und wenn durch ein Handling- Fehler Mist eingelesen wird, sollte man darüber nachdenken, wie sich so etwas ohne sichtbare Folgen reparieren läßt.

Ein denkbares Scenario wäre, wenn der Kanzlei- Mitarbeiter versehentlich nochmals die mandanten- Email vom Vormonat öffnet und den alten Vorlauf ein zweites Mal anklickte.
So etwas fiel früher sofort auf und auch da wurde ein Buchen abgebrochen, wenn die verkehrten Belege vorlagen. Nur konnte der Mitarbeiter in der pre- EDV- zeit die Belege vor dem Buchen sehen.

Re: GdOB i.V.m. ASCII-Import

theo — Thu, 24 Nov 2016 10:11:16 GMT

Der große Unterschied zu den vorherigen Bestimmungen ist auch die Ausweitung der Dokumentationskette/Prüfung vom Steuerberater ( als letztes Glied) auf die Vorsystemen betont wird.

Nach ein paar Gedankenzügen komme ich (vorerst, heute morgen in der Schnittchenpause) zu dem Schluss, dass mein erster Post immer noch top ist.

Ausgangsdaten des Mand. GoBD-konform archivieren, in-/extensive Prüfung durch den stl. Berater bzw. seine Mitarbeiter inkl. gesetzeskonformer Verbuchung, Festschreibung, Sendung. Für einen 'sachkundigen Dritten' bietet sich zu jeder Zeit ein komplettes Bild durch den Vergleich In- vs. Output.

'Fehler', 'Korrekturen' etc. die 'unterwegs' geschehen, haben keine Relevanz. Die Technik ist kompliziert u. der Azubi muss ja auch mal eingearbeitet werden.

Re: GdOB i.V.m. ASCII-Import

uwes — Thu, 24 Nov 2016 13:37:00 GMT

Hallo,

danke für die vielen Antworten. Das ist aber für mich nicht zielführend. Ich brauche Antworten auf meine Fragen und keine Diskussion ob das Sinn macht oder nicht. Die Sinnigkeit hängt einfach vom Unternehmen ab.

In einer Buchhaltung, wo 5 Leute rumbuchen, von denen einige nicht die Zusammenhänge kennen, macht die Festschreibung absolut Sinn. Ansonsten sind rausgegebene BWA's plötzlich komplett anders oder Umsatzsteuervoranmeldungen passen nicht zum Buchungsbestand.

Als Einzelkämpfer weiß ich jedoch was ich tue, gehe aber nicht weiter daruaf ein.

Was manche schreiben hier, verblüfft mich etwas.

So: Man soll den Stapel vor dem Einlesen prüfen. Gute Idee. Stellt Datev ein Prüfmodul zur Verfügung, oder wie testet man bei ca. 3.000 bis 7.000 Buchungszeilen MONATLICH, ob alle Sätze in Ordnung sind. Das manuell zu prüfen ist wohl eher Theorie.

Oder einer schreibt. Kompletten Stapel als Generalumkehr stornieren. Totschlagargument: Ordnungsgemäße Buchführung.

Wenn ich nur drei Stapel im Jahr versemmeln würde, hätte ich ca. 15.000 bis 20.000 Stornierungen PLUS die natürlich falsch eingelesenen Sätze in gleicher Anzahl, somit 30.000 bis 40.000 Buchungen, die absoluter Datenmüll sind ohne jedliche Bedeutung, da es ja keine Falschbuchungen sind, sondern nur technische Unpässlichkeiten.

Entschuldigung: Zu den GOB's gehören natürlich auch Klarheit und Übersicht und Nachvollziehbar für einen fremden Dritten.

Entschuldigung: Aber das ist für mich an der Stelle nichtmehr gegeben.

Gut man kann die Generalumkehrsätze ausblenden, aber physisch sind sie da und müssen erstmal bei einer Betriebsprüfung erklärt werden. Ich weiß nicht wie ein Prüfer reagiert, wenn man ihm sagt: Sorry Alter, ich hab mal eben 40.000 Sätze falsch verarbeitet. Bleib mal ganz gechillt.

Abgesehen davon geht das Datenvolumen für Datensicherungen, Datenaustausch unnötig nach oben.

Also bitte keine Diskussion über Sinnigkeit, wie gesagt, das ist für jeden einfach anders interpretiert. Danke.

VG UweS

Re: GdOB i.V.m. ASCII-Import

Katharina_Schoenweiss — Fri, 25 Nov 2016 13:28:24 GMT

Hallo Zusammen,

gerne nehmen wir zu Ihren Anfragen Stellung.

Zu Ihrem Beitrag UweS:

Frage 1:

In 2017 kann ich nachwievor noch über NUKO diesen Quatsch aufheben - RICHTIG ?

Richtig! In 2017 können Sie weiterhin die Festschreibung beim Import über das NUKO-Recht aufheben.
Eine Änderung wird es ab 2018 geben. Dann gilt das NUKO-Recht nicht mehr für ASCII-Daten ohne Festschreibekennung.

Frage 2:

in meinen csv-Importen reicht mir also, wenn ich das Feldkennzeichen Feschreibung einfüge und in jeder Buchungszeile eine "0" eintrage - RICHTIG ?

Richtig!

Frage 2a:

Herkunft-Kz kann ich mir also sparen ?

Ja, das können Sie.

Frage 2b:

Was passiert wenn bei einem Satz etwas anderes als Null drin steht, also eine "1"

Wenn in einer einzigen Zeile eine „1" drin steht, wird der Stapel festgeschrieben.
Ab 2017 gilt dies auch, wenn die Spalte Festschreibung in einer Zeile leer ist.

Frage 3:

Wird es dann ab 2018 so sein, dass wenn ich einen laufenden Buchungsstapel habe und in diesen einen Import aus einem Fremdsystem mache, dann dieser Buchungsstapel einfach geschlossen wird ???? Oder bleibt ein vorhandener offener Buchungsstapel auch immer weiterhin offen. Dann wäre mein Problem schon gelöst, andernfalls grenzt das Ganze an eine Katastrophe.

Wenn Sie einen Buchungsstapel mit Festschreibung = Ja (bzw. der „1" in der Spalte Festschreibung) importieren, dann wird dieser als neuer Buchungsstapel importiert. Das Anhängen an einen bestehenden, nicht festgeschriebenen Buchungsstapel ist nicht möglich. Diese Logik gilt heute schon.

Zu Ihrem Beitrag Herr Kolberg:

Eine solche Möglichkeit wird es nicht geben. Die Postversanddaten sind von DATEV zum 31.12.2017 abgekündigt und können danach nicht mehr importiert werden.

Fremdanwendungen, die heute noch Postversanddaten exportieren müssen bis spätestens zum Jahreswechsel 2017/2018 auf das DATEV-Format umstellen.

Weitere Informationen finden Sie im Dokument 1080843 Postversandformat wird abgekündigt - Vorgehen für die Umstellung

DATEV-Format-Dateien und ASCII-Dateien lassen sich für einen „unverbindlichen Blick" z. B. in Excel öffnen.

Mit freundlichen Grüßen

Katharina Schönweiß

Service Rechnungswesen (FIBU)

DATEV eG

Re: GdOB i.V.m. ASCII-Import

theo — Sat, 26 Nov 2016 05:43:23 GMT

Zu Ihrem Beitrag Herr Kolberg:
Es muß doch eine GoBD- konforme Möglichkeit geben, daß der normale Anwender einen unverbindlichen Blick in die Postversanddaten werfen kann, bevor er diese endgültig in einer Buchhaltung mit automatischer Festschreibung importiert.
Eine solche Möglichkeit wird es nicht geben. Die Postversanddaten sind von DATEV zum 31.12.2017 abgekündigt und können danach nicht mehr importiert werden.
[,,,]
DATEV-Format-Dateien und ASCII-Dateien lassen sich für einen „unverbindlichen Blick" z. B. in Excel öffnen.

Ich denke 'Postversanddaten' ist hier als Synonym für 'alle Importwege' zu sehen (so ähnlich wie dass man bspw. 'Vorläufe' gemeinhin auch immer noch 'Vorläufe' nennt)

Textformate finden wir natürlich immer toll, jedoch entspricht es nicht den Grundsätzen ordnungsgemäßer Workflows erst

- zu importieren
- Quatsch zu sehen
- alles zu canceln

- Textverarbeitung zu benutzen

- Quatsch zu fixen

u. danach nochmal von vorne anzufangen.

Re: GdOB i.V.m. ASCII-Import

mkolberg — Sat, 26 Nov 2016 08:26:32 GMT

Gibt es bereits eine Lösung für die Problematik:

"Kassenerfassung für Office: Lerndateien in Kanzlei-Rewe erstellen"

https://archiv.datev-community.de/index.php?r=topic%2Fview&id=82076

Die Anforderung, Daten im DATEV-Format ebenfalls als Buchungsvorschläge zu übernehmen, wurde damals lediglich "für die Produktweiterentwicklung vorgemerkt".

Folglich wurde der Uralt- Workflow über die Postversanddaten, der auch heute noch perfekt funktioniert, nicht mehr geändert.

Selbiges gilt für Exporte aus Mandanten- Systemen, wo wirklich niemand das heute wirklich funktionierende System anfassen möchte.

Frage in die Runde: Wäre es denkbar, ein Konvertierprogramm zu nutzen, wenn das Mandantensystem keinen CSV- Export unterstützen sollte?

Gibt es Empfehlungen, so kanzleiintern der Umstieg auf das aktuelle Fomat zeitnah erfolgen könnte?

Re: GdOB i.V.m. ASCII-Import

theo — Sat, 26 Nov 2016 08:54:04 GMT

Gibt es bereits eine Lösung für die Problematik:
"Kassenerfassung für Office: Lerndateien in Kanzlei-Rewe erstellen"
https://archiv.datev-community.de/index.php?r=topic%2Fview&id=82076
Die Anforderung, Daten im DATEV-Format ebenfalls als Buchungsvorschläge zu übernehmen, wurde damals lediglich "für die Produktweiterentwicklung vorgemerkt".

Na immerhin gibts es ja eine 'Perspektive' auf Zeitnahe Umsetzung. Es sei denn die Datev will pünktlich zum 1.1.2018 ihre Importfunktion dafür kaputtschießen.

Folglich wurde der Uralt- Workflow über die Postversanddaten, der auch heute noch perfekt funktioniert, nicht mehr geändert.

Sind Sie sich da sicher. Ich war der Meinung, dass es jetzt 2 Klicks mehr sind (Vorbelegung der Datei auf 'Datev-Format).

Re: GdOB i.V.m. ASCII-Import

uwes — Sat, 26 Nov 2016 10:05:52 GMT

Hallo Frau Schönweiß,

jetzt weiß ich zumindest Bescheid, was ich alles zu tun habe.

Dass mir das nicht gefällt was Datev da macht ist ja ein anderes Thema 🙂

Ganz herlichen Danke für diese Antwort.

Viele Grüße

UweS

Re: GdOB i.V.m. ASCII-Import

Katharina_Schoenweiss — Wed, 30 Nov 2016 13:35:54 GMT

Hallo Herr Kolberg,

die Möglichkeit Daten im DATEV-Format als Buchungsvorschläge zu übernehmen, wird es voraussichtlich in Kanzlei-Rechnungswesen mit der Version 6.0 geben.

Die Auslieferung der DVD 11.0 ist für Mitte 2017 geplant.

Mit freundlichen Grüßen

Katharina Schönweiß

Service Rechnungswesen (FIBU)

DATEV eG

Re: GdOB i.V.m. ASCII-Import

mkolberg — Thu, 01 Dec 2016 05:54:39 GMT

Sehr geehrte Frau Schönweiß,

Danke für die rechtzeitige Bestätigung, daß der das DATEV- Format auch im Jahr 2017 nicht genutzt werden darf. Wir werden folglich den Mandanten weiterhin bitten, bei der Excel- Kasse das Postversand- Format zu verwenden.

Wenn wir in der Kanzlei erst zur Herbst DVD überhaupt mit dem neuen Format umgehen können, werden wir vom Mandanten auch nicht früher die Umstellung mit Testläufen usw. erwarten können. Auch müssen wir hausintern lernen, mit den neuen Formaten, Dateinamen usw. umzugehen und gewisse Dinge, wie Dateipfade Arbeitsablaufdokumentationen usw. müssen für die nicht EDV- Fachfrauen der Buchhaltung neu eingerichtet werden.

Realistisch ist es, daß wir beim Mandanten mit den Upgrade auf die Excel- Kasse 2018 zum Jahreswechsel diese Umstellung einfordern können.

Voraussetzung ist aber, daß wir zum Jahreswechsel unserem Mandanten die neue Version übergeben können und daß es keinerlei Probleme mit dem Einspielen gibt.

Aus diesen Gründen bitte ich darum, dem Abschaltungstermin vom Postversand- Format um ein Jahr zu verschieben, oder ... noch besser ... dieses Format für alle Ewigkeit einfach da zu lassen, wo es sich heute befindet. Programmintern muß doch nur ein dummer Konverter die Postversand- Daten in das aktuelle Format konvertieren, welches dann zu verarbeiten ist. Da sich an diesem Format nichts mehr ändern wird, erwarte ich auch keine teuren Pflegeaufwendungen in der Zukunft und die Mandanten, die noch immer mit einem DOS- Programm vorerfassen, dürfen so weiter machen.

PS (Frage an Kollegen)

Es gibt diverse Format- Konverter. Welches Programm ist gut geeignet, um Postversand- Daten komfortabel ins DATEV- Format zu wandeln, mit wählbarem Festschreibungs- Falg, da nur der Sachbearbeiter weiß, ob er eine endgültige Buchhaltung oder nur eine Vorerfassung vom Mandanten einspielen möchte.

Re: GdOB i.V.m. ASCII-Import

Gelöschter Nutzer — Thu, 01 Dec 2016 06:59:46 GMT

Hallo Frau Schönweiß,

Frage 1:
In 2017 kann ich nachwievor noch über NUKO diesen Quatsch aufheben - RICHTIG ?
Richtig! In 2017 können Sie weiterhin die Festschreibung beim Import über das NUKO-Recht aufheben.
Eine Änderung wird es ab 2018 geben. Dann gilt das NUKO-Recht nicht mehr für ASCII-Daten ohne Festschreibekennung.

ich nehme die Aussage erst einmal so hin, da ich dann über den CSV-Import gehen. Dennoch stelle ich mir die Frage, warum die DATEV so restriktiv sein muss? Ist dieses zwangsweise Festschreiben eine unumstößliche Vorausetzung an eine ordnungsgemäße Buchaltungssoftware?

Wenn ja, dann ist das Thema hier beendet.
Wenn nein, warum reicht es dann nicht einfach aus, dass in dem Tätigkeitsprotokoll vermerkt wird, dass Buchungsdaten importiert wurden und der Anwender willentlich die Zwangsfestschreibung aufgehoben hat. Dann hat der Anwender, bei Aufforderung in dern BP, die Erklärungsnot. Die DATEV ist dann ja raus.

Frage 2b:
Was passiert wenn bei einem Satz etwas anderes als Null drin steht, also eine "1"
Wenn in einer einzigen Zeile eine „1" drin steht, wird der Stapel festgeschrieben.
Ab 2017 gilt dies auch, wenn die Spalte Festschreibung in einer Zeile leer ist.

Ich habe mir bereits ein globales Konvertierungstool erstellt, der mir die Daten standartisiert ausgibt. Für uns stellt sich daher das Problem nicht. Bei Exporten aus Fremdprogrammen (z. B. Lexware) muss ich dann halt unbedingt darauf achten, dass zukünftig nur noch ein ASCII-Export zulässig ist.

Oder als Alternative:

Man richtet sich ein Dummy-Mandanten ein. Liest hier immer die Daten ein und exportiert diese dann einfach aus der Primanota-Ansicht und ändert anschließen das Festschreibungskennzeichen. Die Vorlaufdaten wären dann natürlich immer zu berichtigen. Ist keine schöne Lösung, sollte aber funktionieren.

Gruß A. Martens

Re: GdOB i.V.m. ASCII-Import

alterpraktiker — Thu, 01 Dec 2016 07:03:18 GMT

Das was DATEV hier plant kann so niemals umgesetzt werden.

Wir brauchen auch in Zukunft die Möglichkeit Buchungsdaten jeglicher Art vorher zu bearbeiten.

Wenn DATEV sich erlaubt das nicht mehr anzubieten wird es sehr großen Ärger geben.

Wir werden das jedenfalls nicht akzeptieren.

Re: GdOB i.V.m. ASCII-Import

alterpraktiker — Thu, 01 Dec 2016 07:07:40 GMT

Frau Schönweiß: "DATEV-Format-Dateien und ASCII-Dateien lassen sich für einen „unverbindlichen Blick" z. B. in Excel öffnen."

Dieser Satz sagt alles über den Zustand von DATEV aus. Wie soll ich in Excel auf die schnelle erkennen ob der Buchungssatz richtig ist? Hier kann ich gerade mal erkennen welche Konten verwendet wurden. Welche steuerlichen Auswirkungen der Buchungssatz hat sieht man doch erst nach dem einspielen in Kanzlei Rechnungswesen.

Dort beginnt die Aufgabe der Steuerberater dem Finanzamt eben keine falschen Buchungen zu liefern. Das Finanzamt wird es uns danken.

Die Denkweise der DATEV ist nicht nach zu vollziehen.

Re: GdOB i.V.m. ASCII-Import

Gelöschter Nutzer — Thu, 01 Dec 2016 07:11:28 GMT

Hallo Alter Praktiker,

Frau Schönweiß: "DATEV-Format-Dateien und ASCII-Dateien lassen sich für einen „unverbindlichen Blick" z. B. in Excel öffnen."

auf diesem Wege habe ich zumindest die Möglichkeit, in der Festschreibungsspalte eine "0" einzutragen und damit eine Festschreibung aufzuheben.

Wie gesagt, ist mir das letztendlich auch zu umständlich. Daher meine Frage nach der Notwendigkeit.

Gruß A. Martens

Re: GdOB i.V.m. ASCII-Import

mkolberg — Thu, 01 Dec 2016 07:20:37 GMT

und... Bei dem "unverbindlichen Blick" kann ich alles Mögliche ändern und nachher schaut es in der Buchhaltung so aus, als hätte der Mandant den Vorlauf so geliefert.

An anderer Stelle wurde bereits vor Ewigkeiten der Wunsch ausgesprochen, daß beim Import von nicht festgeschriebenen Vorläufen auch im DATEV- Format das "SV"- Kennzeichen bei allen Buchungen gesetzt wird, welches sich bei Änderungen vom Kanzlei- Mitarbeiter in "RE" ändert.

Damit ließe sich bei einer BP vom Prüfer sofort erkennen, ob wir Original- Buchungen vom Mandanten haben bzw. welche Buchungen in der Kanzlei nachträglich geändert bzw. neu erfaßt wurden. Beispiel: UST- Schlüssel ist einer größeren Rechnung verkehrt gesetzt.

Neuer Wunsch / Anregung:

Der Buchungssatz wird um die Felder: "erstellt am" und "geändert am" erweitert, welche vom System automatisch gesetzt werden. Neben Dokumentationsfunktionen würden diese Felder dem Sachbearbeiter die Möglichkeit eines Sortierens nach dem Erfassungszeitpunkt geben, so daß sich die Buchungen auf den Kontoblättern in exakt der Reihenfolge anzeigen lassen, wie diese erfaßt wurden. Auch bei Streitigkeiten könnten diese Felder in Verbindung mit dem Aktivitäten Protokoll klären, wer letztlich den Buchungssatz so erfasst hatte.

Re: GdOB i.V.m. ASCII-Import

Gelöschter Nutzer — Thu, 01 Dec 2016 07:36:37 GMT

Hallo Hr. Kolberg,

hier einmal bei mir ein typisches Aktivitätsprotokoll:

Man kann also sehr schön erkennen, wer - was - wann getan hat. Erst wurden Importe durchgeführt mit entsprechender Information. Das sollte doch IMO völlig ausreichen.

Schön ware es natürlich, wenn zusätzlich noch eine Kennung der Buchungssätze erfolgt. Es stellt sich nur die Frage, was passiert, wenn ich in dem importierten Vorlauf zusätzlich noch Buchungen vornehme, und was passiert, wenn ich Vorläufe zusammenfasse (also Import u. erfasste)?

Übrigens:

Man kann sehr schön sehen, dass immer vor der Übermittlung die Festschreibung erfolgte, daher ist die Kennzeichnung in der UStVA bei offenen EB-Werten unsinnig. Es ist immer der UStVA-Zeitraum mit dem Buchunghaltungszeitraum zu vergleichen.

Gruß A. Martens

Re: GdOB i.V.m. ASCII-Import

Gelöschter Nutzer — Thu, 01 Dec 2016 07:39:24 GMT

Nachtrag:

Schön wäre es, wenn im Protokoll die Zusammenfassung von Vorläufen nicht als Korrektur, sondern mit Text "Zusammenfassung Vorläufe" gekennzeichnet werden würde (siehe 3. Vorgang). Hier fasse ich die verschiedenen Vorläufe zu einem zusammen.

Gruß A. Martens

Re: GdOB i.V.m. ASCII-Import

mkolberg — Thu, 01 Dec 2016 07:52:53 GMT

Sehr geehrter Herr Martens,

Ich erkenne eine Vorerfassung, die hypothetisch geprüft, festgeschrieben und dann gesendet wurde.

Es läßt sich nun aus dem System nicht mehr erkennen, welche Buchungssätze von Ihnen geändert wurden, um beispielsweise dem Mandanten mitzuteilen, bei welchen Buchungssätzen er in seinem System die Änderungen der Kanzlei nachvollziehen muß, um die Integrität wieder herzustellen.

Daher mein Wunsch, daß man dem Einzel- Buchungssatz auf Dauer ansieht, ob er das importierte Original aus der Fremdsoftware ist, oder ob er nach dem Einspielen geändert bzw. neu erfaßt wurde.

Dieses würde erreicht werden durch folgende Flags:

zuverlässiges SV- Kennzeichen
Feld "erstellt am" (notfalls Import- Datum, wenn es die Fremdsoftware nicht liefert)
Feld "geändert am"

Das sollte programmtechnisch relativ leicht umsetzbar sein, wenn auch eine Änderung von Export- Formaten immer einen Rattenschwanz mit sich zieht...

Re: GdOB i.V.m. ASCII-Import

Gelöschter Nutzer — Thu, 01 Dec 2016 07:54:45 GMT

Ich stimme Ihnen ja zu.

Re: GdOB i.V.m. ASCII-Import

crzeiss — Thu, 01 Dec 2016 08:48:45 GMT

DATEV-Format-Dateien und ASCII-Dateien lassen sich für einen „unverbindlichen Blick" z. B. in Excel öffnen.

ACHTUNG! Nach dem Ansehen in Excel sollte die Csv-Datei auf keinen Fall gespeichert werden! Excel schlägt bei Csv-Dateien aber IMMER vor, die Datei zu speichern.

Grund: Excel interpretiert beim Öffnen der Csv-Datei bestimmte Werte neu und formatiert sie einfach um. So kann ggf. aus einem Betrag 1,12 plötzlich ein Datum 1.12.2016 werden. Das passiert oft mit Angaben, die rein theoretisch Datumswerte sein könnten.

"Auf diesem Wege habe ich zumindest die Möglichkeit, in der Festschreibungsspalte eine "0" einzutragen und damit eine Festschreibung aufzuheben..."

Das sollte man deshalb auf keinen Fall machen.

Re: GdOB i.V.m. ASCII-Import

Gelöschter Nutzer — Thu, 01 Dec 2016 10:41:36 GMT

Hallo Hr. Zeiss,

das Problem kenne ich zwar, taucht bei mir aber praktisch in Bezug auf DATEV nie auf. Daher bleibt es IMO ein probates Mittel.

Außerdem wird es von DATEV ebenfalls empfohlen, um z. B. Rechnungsnummern nachträglich über Excel zu berichtigen. DATEV kennt leider keine automatische Neunummerierung von Belegfeld1 (s. auch mein Post https://www.datev-community.de/message/17428#17428). In der alten Anwendung konnte man ganz bequem nachträglich eine Rechnungsnr. automatisch neu durchnummerieren, da es bsw. einmal eine Rechnungsnummerlücke gab. DATEV kennt das nicht und empfielt hier den Excel-Export (was ich auch bemängele, da dies die Software können müsste).

Gruß A. Martens

Re: GdOB i.V.m. ASCII-Import

uwes — Fri, 02 Dec 2016 01:07:23 GMT

In meinen Importdateien habe ich in der Spitzenzeit ca. 5.000 bis 7.000 Sätze, Tendenz ansteigend.

Die sollen jetzt per Sichtkontrolle in Excel auf Richtigkeit überprüft werden, weil Datev das technisch nicht schafft ?? Wenn es nicht so traurig und ernst wäre, müsste ich schon fast wieder lachen bei dieser Vorstellung.

Was kommt als nächstes ?? Wir nehmen statt Taschenrechner einen Rechenschieber ?

Das kann DATEV wirklich nicht bringen.

Entweder bleibt es so wie es ist, dass ich falsche Vorläufe wieder rauslöschen kann und nochmal neu importieren kann oder es gibt ein Tool, wo ich eine Datei vorher prüfen kann. Ansonsten wird das der Wahnsinn. Wie gesagt. Bei 50 Buchungen ist das egal, da kann man evt. wirklich manuell prüfen oder auch mal wieder stornieren.

Bei meiner Datenmenge, produziere ich definitv Datenmüll in der Datenbank.

VG - UweS

Re: GdOB i.V.m. ASCII-Import

christiankunz — Fri, 02 Dec 2016 07:09:32 GMT

(Hilfs-)Lösung s. Thread vom 20.10. „Automatisches Festschreibung von Vorläufen“ #2.

Grüße und einen schönen Tag!

Re: GdOB i.V.m. ASCII-Import

uwes — Fri, 02 Dec 2016 09:31:23 GMT

Hallo,

als Hinweis. Der Link funktioniert leider nicht, vermutlich wegen der Anführungszeichen. Ich habe aber den Beitrag gefunden.

In diesem Beitrag geht es um Postversanddaten. Die werden ja eingestellt. Abgesehen davon habe ich keine Postversanddaten, sondern ausschließlich csv.

Weiterhin unterscheidet man zwischen falsch und falsch 🙂

Technisch Falsch - das muss Datev helfen beim Einspielen

Inhaltlich Falsch - das sehe ich erst, wenn ich eingespielt habe und Konten abgeliche.

Wir haben einige Schnittstellen, wo wir z.B. Daten aus Paypal auslesen und dann gleich der Kontierung unterwerfen. Wenn Paypal mal mal etwas anders macht, als normal, läuft einfach mal was falsch. Da haben wir keinen Einfluß darauf und müssen einfach mal kurz umkontieren.

Re: GdOB i.V.m. ASCII-Import

christiankunz — Fri, 02 Dec 2016 10:47:04 GMT

Ich bin davon ausgegangen, daß die Datev-Aussage für alle Importformate gilt. Welchen Sinn sollte es denn haben, bei der Festschreibungspolitik nach Formaten zu unterscheiden?

M. E. kann ich also den kompletten importierten, aber nicht festgeschriebenen Vorlauf im Rechnungswesenprogramm anschauen, und bei sonstiger Fehlerfreiheit hätte nur eine einzige, vorab vereinbarte oder selbst hinzugefügte Buchung ein rotes Fehlerkennzeichen.

Daß dieses Vorgehen nur eine Krücke sein kann, steht auf einem anderen Blatt.

Grüße

Re: GdOB i.V.m. ASCII-Import

uwes — Fri, 02 Dec 2016 11:24:07 GMT

Bei Datev setze ich im Moment nichtmehr meinen eigenen Masstäbe voraus. Das ganze Thema, das Datev hier aufreißt ist völlig unnötig. Gründe und Lösungen, die vernünftig sind, wurden hier schon mehrfach genannt.

Würde man Ihrer Logik folgen wäre das gar nicht mal so schlecht in der Praxis. Dann würde ich in meinen Schnittstellen, die ich selbst mache, einfach immer eine gewollte Fehlerzeile hineinprogrammieren.

Wie ich es dann aus Softwareprogrammen mache, die technisch korrekt liefern, müsste ich mir dann überlegen.

Aber interessanter Ansatz.

Danke.

VG Uwes

Re: GdOB i.V.m. ASCII-Import

Gelöschter Nutzer — Fri, 02 Dec 2016 11:28:51 GMT

Hallo Hr. uwes,

aber was hindert Sie daran, in der CSV-Datei eine Spalte mit dem Festschreibungskennzeichen mit Inhalt '0' einzufügen. Das hebt doch die Festschreibung auf, oder habe ich da etwas flasch verstanden.

Gruß A. Martens

Re: GdOB i.V.m. ASCII-Import

uwes — Fri, 02 Dec 2016 11:34:51 GMT

Sehr geehrter Herr Martens,

Sie lesen einfach zu schnell 🙂 Mir ist auch grade aufgefallen, dass ich einen totalen Blödsinn geschrieben habe. Natürlich. Ich passe die Dinger ja sowieso an, die ich selbst mache.
Jetzt geht es halt noch um die Stapel, die ich aus Fremdsystemen bekomme. Evt. leisten die Hersteller mal einen Beitrag mit einem Zusatzkennzeichen. Aber wer weiß das schon ? Meistens halt erst nach einem Jahr, wenn die ersten Anfangen zu begreifen, was das jetzt bedeutet.

VG- UweS

Re: GdOB i.V.m. ASCII-Import

Chris_Pollack — Wed, 07 Dec 2016 15:47:19 GMT

Hallo Community,

die meisten Ihrer Kritikpunkte drehen sich um die Frage ob DATEV mit der strikten Festschreibelogik die GoBD zu streng auslegt. Daher zuerst ein paar Worte dazu.

Die GoBD verlangen eine Nachvollziehbarkeit der Buchführung die sich auch auf die Vor- und Nebensysteme erstreckt. Überall dort, wo Buchungsdaten importiert werden stammen diese Daten aus einem Vorsystem. Wenn Buchhaltungsdaten aus einem Vorsystem exportiert werden, die dort unveränderlich sind, dürfen sie auch im DATEV Programm nicht mehr geändert werden. Dies erreichen wir mit der direkten Festschreibung der importierten Buchungsstapel.

Streng genommen kann ein Prüfer die Buchführung bemängeln, wenn er feststellt, dass Buchungen, die im Vorsystem festgeschrieben sind in Kanzlei-Rechnungswesen nach dem Import geändert wurden. Ob dies in der Praxis passieren wird, weiß heute noch niemand. Es fehlt die Rechtsprechung dazu.

Sie haben als Anwender mit dem NUKO-Sonderrecht die Möglichkeit bekommen die Festschreibung aufzuheben. Die Verantwortung dafür tragen Sie. Im Zweifel müssen Sie dem Prüfer erklären können warum Sie die Festschreibung aufgehoben haben. Dasselbe gilt für die „Manipulation" der Dateien vor dem Import durch Editieren des Festschreibekennzeichens. Ich kann von einem solchen Vorgehen nur abraten. Sie wissen heute noch nicht welche Konsequenzen das bei einer Prüfung in Zukunft haben kann.

Lassen Sie mich nun auf einige Ihrer Beiträge konkret eingehen.

Herr Kolberg, die Postversanddateien werden abgeschafft. Die GoBD sind der Anlass, aber nicht der einzige Grund. Das Format ist technisch veraltet und mit jeder Weiterentwicklung der Buchungszeile bzw. der Stammdatenfelder bekommen wir mehr Probleme mit diesem Format.

Ja, das ist mit Umstellungsaufwand verbunden und ja, einige Mandanten werden sich vielleicht eine neue Software suchen müssen, wenn der Hersteller der Software seine Schnittstellen nicht anpasst. Wir kennen auch viele Fälle bei denen der Mandant seit Ewigkeiten keine neue Version seiner Software installiert hat und das aus Kostengründen nicht tun möchte. Ob diese dann noch auf dem aktuellen gesetzlichen Stand ist, darf bezweifelt werden.

DATEV passt zum Jahreswechsel alle internen Schnittstellen an, sodass hier überall ein Festschreibekennzeichen mit kommt. Die Ausnahme bilden hier die Buchungsvorschläge aus der Kassen- und Warenerfassung Office, die erst ab der DVD 11.0 im DATEV-Format funktionieren. Da es sich bei Buchungsvorschlägen um vorläufige Buchungen handelt ist hier keine Festschreibung betroffen.

UweS, Sie wünschen sich ein Tool mit dem man vor dem Import die Daten prüfen kann. Denken wir diesen Wunsch zu Ende. Sie unterscheiden beim Import zwischen falsch und falsch. Ich gehe noch einen Schritt weiter und unterscheide zwischen falsch, falsch und falsch.

Technisch falsch: Hier liegt ein Fehler im Dateiformat vor. Die Datei kann nicht eingespielt werden. Es kommt eine entsprechende Fehlermeldung. In einigen Fällen können wir helfen, in anderen nicht. Für unsere Diskussion ist dieser Fall irrelevant.

Fachlich fasch: Die Datei ist technisch in Ordnung und kann importiert werden. Einzelne Buchungen widersprechen der DATEV-Buchungslogik. Beim Import werden Fehler und/oder Hinweise im Importprotokoll ausgewiesen. Die Buchungen können als fehlerhafte Buchungen importiert werden. Eine evtl. vorhandene Festschreibung wird aufgehoben um diese Fehler im Anschluss an den Importvorgang korrigieren zu können. Die Aufhebung der Festschreibung aufgrund fehlerhafter Buchungen wird im Aktivitätenprotokoll vermerkt. Hier wird kein Tool benötigt. Die Fehler stehen im Importprotokoll und die Buchungen stehen in offenen Buchungsstapeln.

Inhaltlich falsch: Um diese Fälle geht es Ihnen. Die Datei ist korrekt und auch die Buchungen entsprechen der DATEV-Buchungslogik. Trotzdem wurde etwas falsch gebucht. Doch was soll von Programmseite hier geprüft werden? Wir können nur auf die Buchungslogik prüfen. Wir können unmöglich wissen, ob die Buchhaltung korrekt ist. Woher soll das Programm das wissen?

Woher wissen Sie das? Ich nehme an Sie erkennen das daran, dass die Werte auf den Auswertungen nicht stimmen. Die Werte auf den Auswertungen sehen Sie aber nur, wenn die Buchungen bereits verarbeitet sind. Eine Art „vorläufige Verarbeitung" um diese Buchungen in ihren Auswirkungen auf die Auswertungen prüfen und ggf. korrigieren zu können würde wiederum eine Aufhebung der Festschreibung bedeuten. Genau das darf aber nicht passieren. Der korrekte Weg im Sinne der GoBD ist hier eine Generalumkehr der falschen Buchungen.

Eine Generalumkehr ist aktuell nur für den kompletten Buchungsstapel oder manuell für jeden einzelnen Buchungssatz zu erfassen. Zu Recht empfinden Sie das als umständlich. Ab Programmversion 5.3 (DVD 10.1, Januar 2017) werden wir in den Rechnungswesen-Programmen eine Eingabeerleichterung für die Generalumkehr haben.

Sie werden in der geöffneten Primanota eines festgeschriebenen Stapels eine beliebige Anzahl Buchungen per Mehrfachauswahl markieren können und dann über das Kontextmenü eine Funktion „Buchungen bearbeiten" aufrufen können. Damit erzeugen Sie Generalumkehrbuchungen für die markierten Buchungssätze in einem neuen Buchungsstapel und optional im selben oder einem weiteren Stapel eine Kopie der ursprünglichen Buchungen, die Sie im Anschluss korrigieren können.

Mit freundlichen Grüßen

Chris Pollack

Service Rechnungswesen (FIBU)

DATEV eG

Re: GdOB i.V.m. ASCII-Import

mkolberg — Wed, 07 Dec 2016 19:02:08 GMT

Sehr geehrter Herr Pollack,

Leider sind Sie auf meine Wünsche betreffs der Änderungshistorie in der einzelnen Buchungszeile nicht eingegangen.

Seit Ewigkeiten hatten wir das SV- Kennzeichen, welches sich beim Editieren in der Kanzlei auf RE änderte. Weshalb wurde das abgeschafft?

Mit dieser Abschaffung haben wir die Nachvollziehbarkeit von Änderungen komplett verloren.

Technische Fehler entstehen auch dadurch, daß im Vorsystem UST- Automatiken hinterlegt sind, die in Zielsystem nicht vorhanden sind oder im Vorlauf- Header verkehrte Daten stehen..

Da ist es notwendig, nach dem Einspielen eines Vorlaufes diesen entweder manuell zu korrigieren (9- er Schlüssel erfassen) oder komplett in die Tonne zu treten, um nach der Änderung einen zweiten (oder dritten und vierten) Versuch zu starten.

Nochmals Danke für die Prüfung.

Insbesondere, daß geprüft wird, wann die automatische Festschreibung passiert.

Es wäre doch denkbar, eine allgemeine "undo"- Funktion einzubauen, so daß der Mitarbeiter ein verkehrtes Importieren so canceln kann, daß dieser Import nie stattgefunden hat. Auch wäre es denkbar, daß die NuKo- Ausnahme nicht beim Importieren greifen muß. Sinnvoller wäre es doch, wenn diese NuKo- Ausnahme erst dann die Festschreibung aufhebt, wenn der Mitarbeiter wirklich den Stapel zum Ändern öffnen möchte.

Situation heute:

Jeder Stapel wird sicherheitshalber per NuKo ausgehebelt, da er Fehler beinhalten könnte.
Dann wird meistens doch ohne Änderung gesendet

Situation erwünscht:

Jeder Stapel wird erst einmal in festgeschriebener Form eingespielt.
der Mitarbeiter kann diesen Stapel per NuKo- Freigabe editieren, wobei das im Aktivitätenprotokoll festgehalten wird.

Re: GdOB i.V.m. ASCII-Import

uwes — Thu, 08 Dec 2016 02:04:37 GMT

Hallo Herr Pollack,

danke für die Ausführungen. Manches ist mir jetzt klar geworden, wie es technisch laufen wird und was noch kommt.

Aber:

"Sie haben als Anwender mit dem NUKO-Sonderrecht die Möglichkeit bekommen die Festschreibung aufzuheben" verstehe ich so, als ob das gesetzt ist. Wenn ich das aber richtig verstehe gilt das noch bis 2017 (habe es derzeit schon eingestellt). Wenn das über 2017 hinaus möglich ist, wäre doch schon alles erledigt.

Nun das mit der Festschreibung, weil es in fremder Software nichtmehr änderbar ist, ist für mich kein Argument, weil:

a) Wenn in der Fremdsoftware festgeschrieben, aber ein techn. Fehler auftritt, der Stapel ja auch nicht festgeschrieben werden kann in Datev - somit existiert ja auch keine endgültige Sicherheit. Also die Logik geht nicht auf.

b) ich Daten aus einem nicht fixen Fremdsystem ziehe, sondern nur Datenmaterial aufarbeite. Beispiel: Ich ziehe die Bewegungsdaten aus Paypal in eine csv.Datei. Diese csv-Datei wird in Excel mit einem Makro kontiert, von da aus geht es in eine Accessdatenbank und es werden die Ausgaben für Verkauf, Umbuchungen, Gebühren und Einkauf erstellt. Also - es ist nix im Fremdprogramm festgeschrieben, es können hier immer noch technische, als auch inhaltliche Fehler passieren. Meistens stimmt aber alles :-). Also keinen Bezug zwischen Buchungsstapel und irgendeiner Fremdsoftware.

Aber gut - lange Rede kurzer Sinn:

Ich werde versuchen in alle Buchungsstapel ein Festschreibekennzeichen "0" reinzubeamen und damit ist der Fall erledigt. Ich hoffe, die Softwarehersteller ziehen da alle nach.

Bis jetzt war noch immer alles irgendwie zu lösen. Lassen Sie doch einfach das ganze in der NUKO als Sondernutzungsrecht und alle sind happy. Dann kann es jeder machen wie er will. Entweder streng nach Vorschrift - die im Moment außer der Datev sowieso keinen interessiert oder eben mit leichten Risiko die großzügiger Auslegung. Ich denke wenn man zur Umsatzsteuer die Vorläufe abschließen muss ist ein guter Kompromiss, auch mit der Finanzverwaltung.

Wenn es nicht geht, muss man halt über andere Software nachdenken. Im Moment will ich an Datev festhalten, aber mir wurden schon Unterlagen vorgelegt von anderen Softwarehäusern zwecks Prüfung, weil dieses Thema bei uns in der Tat negativ aufschlägt.

PS: Ich bin es z.B. gewohnt, dass ich für einen Monat in der Regel einen Stapel habe. Stapel Januar, Stapel Februar usw.

Künfitg habe ich dann Stapel Jan laufend, Stapel Jan ERP, Stapel JAN Kasse, Stapel Jan Paypal, Stapel Jan Moneybookers, Stapel Jan Amazon, Stapel Jan Lohn usw.
Sorry, ja das ist möglich und machbar. Für mich aber völlig sinnfrei und übersichtlicher wird es dadurch auch nicht.

VG
UweS

Re: GdOB i.V.m. ASCII-Import

mkolberg — Thu, 08 Dec 2016 05:11:43 GMT

Vielleicht sollte hier einmal zusammengetragen werden, in welchen Situationen hier der Import noch genutzt wird.

Selbstgestrickte Tabellen für Payal, Banken, Kassen usw.
Datev- Kasse (mit Lerndatei)
Buchungen aus anderen Mandanten bei Verrechnungskonten
Selbstgestrickte Tabellen für den OPOS- Ausgleich
regelmäßig widerkehrende Buchungen

in diesen Fällen läuft der Workflow so ab:

Tabelle (also CSV- Datei) erstellen
Import in laufende Buchhaltung
Überprüfen, Editieren, Gegenkonto korrigieren. usw.
Wenn OK, festschreiben und Senden.

Natürlich gibt es noch den selbstbuchenden Mandanten, der uns seine Daten (z.B. Ausgangsrechnungen) zum Import zuspielt. Da macht das automatische Festschreiben Sinn, aber auch hier muß es nach dem Import eine Möglichkeit geben, eine Reparatur durchzuführen. Stellen Sie sich vor, der Mandant hat im Dezember- Export versehentlich nochmals alle November- Rechnungen beigefügt.

Was soll die Kanzlei jetzt tun?

Ja, es bleibt die Möglichkeit, in Rewe eine Rücksicherung auf den Vortag durchzuführen. Aber kann es keine andere Lösung geben? z.B. Per NuKo- Recht eine Festschreibung nachträglich aufheben (Mit Erfassung des Grundes herfür)

der Wunsch ist, daß bei den Ausgangsrechnungen keine Abweichung zum Vorsystem entsteht und später der Prüfer nicht fragt, weshalb hier 5.000 Rechnungen storniert wurden. der Prüfer soll in diesem Fall sehen, daß es Re- Nr. x1 bis x2 gibt, und daß sich auf dem Konto exakt so viele Buchungen befinden. Ich gebe einmal davon aus, daß beim GDPDU- Export die Ausziffer- Funktionalitäten nicht dazu führen, daß beim Betriebsprüfer der komplette generelumgekehrte Mist nicht für Verwirrung sorgt.

Re: GdOB i.V.m. ASCII-Import

alterpraktiker — Thu, 08 Dec 2016 08:34:47 GMT

Sie schreiben: "Die GoBD verlangen eine Nachvollziehbarkeit der Buchführung die sich auch auf die Vor- und Nebensysteme erstreckt. Überall dort, wo Buchungsdaten importiert werden stammen diese Daten aus einem Vorsystem. Wenn Buchhaltungsdaten aus einem Vorsystem exportiert werden, die dort unveränderlich sind, dürfen sie auch im DATEV Programm nicht mehr geändert werden. Dies erreichen wir mit der direkten Festschreibung der importierten Buchungsstapel."

Das Vorsystem ist bei uns z.B. ein Excel Export aus einer Fakturasoftware, aus SAP oder woher auch immer. In diesen Vorsystemen wird keine Buchhaltung oder Buchungen im Sinne der GobD erstellt. Mit dem Excel Export und anschließendem ASCII Import bei DATEV REWE erleichtern wir uns die tägliche Arbeit um nicht 1000 oder mehr Rechnungen per Hand einbuchen zu müssen.

Diese Dateien enthalten teilweise nicht einmal Erlös oder Kostenkonten, EU Funktionen etc. etc.. Je nach Möglichkeit des Mandanten.

Also bitte DATEV unterscheiden Sie bitte zwischen echten Vorsystemen, wie eine vom Mandanten eigenverantwortlich geführte Kasse, Daten aus Unternehmen online, KHK etc. bei denen der Mandant Buchungen tätigt und technischen Abläufen bei denen keinerlei Vorverbuchung stattgefunden hat.

Für diese, zur Zeitersparnis in der Kanzlei entwickelte Szenarien, können Sie uns nicht ständig mit unsinnigen, und auch vom Gesetzgeber so nicht gewollten, Festschreibungsszenarien bei der Arbeit behindern und die Personalkosten in der Kanzlei in die Höhe treiben.

Re: GdOB i.V.m. ASCII-Import

mkinzler — Thu, 08 Dec 2016 08:44:18 GMT

Dann schalten Sie für diese Mandanten doch einfach die automatische Festschreibung in der Nuko ab.

Re: GdOB i.V.m. ASCII-Import

uwes — Thu, 08 Dec 2016 10:09:57 GMT

lt. Datev geht das nur bis 2017 - und dann ?????

Re: GdOB i.V.m. ASCII-Import

Chris_Pollack — Thu, 08 Dec 2016 12:08:38 GMT

Hallo Community,

die Wünsche von Herrn Kolberg und allen anderen werden von uns selbstverständlich aufgenommen und an die Entwicklung zur Prüfung weitergeleitet, auch dann, wenn ich nicht explizit in der Diskussion auf sie eingegangen bin. Dazu ob und wann sie realisiert werden können wir noch keine Aussage treffen.

Ich verstehe Ihren Wunsch nach einer „undo"-Funktion. Die Möglichkeiten für Fehlerquellen beim Datenaustausch zwischen Fremdanwendungen und DATEV-Software sind enorm. Sie könnten noch viele weitere Beispiele nennen. Ich erlebe täglich teils haarsträubende Fälle im Service. Ein einmal importierter Stapel unterscheidet sich jedoch nicht mehr von einem selbst erfassten Stapel. Mit der „undo"-Funktion wünschen Sie sich damit nichts anders als ein außer Kraft setzen der Festschreibung allgemein.

Die Beispiele die Herr Kolberg, UweS und Alter Praktiker nennen betreffen jeweils selbst erstellte Importdateien bzw. vorläufige Buchungen. Hier gibt es kein Vorsystem mit unveränderlichen Buchungen. Das Erstellen der Importdatei mit Festschreibekennung 0 (keine Festschreibung) ist völlig in Ordnung. Deswegen gibt es die Festschreibekennung. Wir wollen unterscheiden können.

Das NUKO-Sonderrecht wird es für Importdateien mit Festschreibekennung auch nach 2017 noch geben. Für Formate ohne Festschreibekennung wird es nicht mehr gelten. Da es in Textform nicht immer ganz einfach ist zu beschreiben in welchem Fall wann was möglich ist empfehle ich Ihnen die Übersichtsgrafik am Ende von Info-Dokument 1080697. Darin sind alle Möglichkeiten dargestellt. Es hält sich leider hartnäckig das Gerückt, dass das NUKO-Sonderrecht nach 2017 komplett abgeschafft wird. Leider ist das unsere eigene Schuld. Es stand tatsächlich eine Weile so auf der Info-Datenbank. Die entsprechenden Dokumente wurden inzwischen korrigiert. Sollten Sie noch ein Dokument finden auf dem das falsch steht, bin ich für einen Hinweis dankbar.

UweS, bei Ihrem Beispiel a) haben Sie natürlich Recht. Als Alternative bliebe noch den Buchungsstapel komplett abzulehnen ohne nur die fachlich korrekten Buchungen zu verarbeiten und die fehlerhaften Buchungen in einem neuen Stapel nachzufassen. Alle drei Möglichkeiten werden Ihnen in einem Auswahldialog nach dem Schließen des Importprotokolls gegeben. Die Nachvollziehbarkeit bleibt allerdings auch im Fall der Verarbeitung von fehlerhaften Buchungen bestehen. Die fehlerhaften Buchungen können über das Importprotokoll nachvollzogen werden.

Herr Kolberg, meinen Sie das Ausziffern auf den FIBU-Konten mit aktivierter OPOS-Funktionalität? Hier werden keine echten Buchungen erzeugt. Das ist nur eine Ansichtsoption im FIBU-Konto, die Ihnen das Abstimmen erleichtert.

Mit freundlichen Grüßen

Chris Pollack

Service Rechnungswesen (FIBU)

DATEV eG

Re: GdOB i.V.m. ASCII-Import

mkolberg — Thu, 08 Dec 2016 12:59:40 GMT

Mit "Undo" meine ich, daß jede Aktion, die ich tätigte Schritt für Schritt rückgängig gemacht werden kann. z.B. das versehentliche Ändern eines Buchungssatzes, der eigentlich per F8 kopiert werden sollte, dann aber doch versehentlich in der Editier- Zeile landete.
Oder das Erfassen einer verkehrten Kontonummer zur Selektion "Kontenblatt", eine geänderte Sortierung usw. , also all die Dinge, wo man als Anwender Fehler macht, und diese trivialen Eingabefehler mit einem Klick ungeschehen machen möchte.

Nein, ich meine nicht die Ausziffer- Funktionen, sondern die neu angekündigte Möglichkeit, generell alle generalumgekehrten Buchungen ausblenden zu können.

Weshalb kann man es nicht programmtechnisch markieren, daß sich ein importierter Stapel solange von selber editierten Stapeln unterscheidet, bis der Anwender in diesen Stapel einen neuen bzw. geänderten Buchungssatz speicherte.

Wir bekommen hier Postversanddaten aus dem Vorsystem, die leider immer wieder fehlerbereinigt werden müssen, bis hin zu der Problematik, daß einzelne Vorläufe vom Mandanten im Zielsystem auf die Monate aufgeteilt werden müssen, da z,B. im November- Vorlauf schon 200 Dezember- Rechnungen enthalten sind.

-> November einspielen ... Fehler Ok... fertig

-> selben Vorlauf; Kopfdaten ändern und im Dezember einspielen -> Alle Nov. Dubletten raus, und perfekt...

Wie gesagt. alte Postversand- Daten und wir sind froh, daß es überhaupt funktioniert.

Re: GdOB i.V.m. ASCII-Import

wielgoß — Thu, 08 Dec 2016 13:28:11 GMT

Hallo Herr Kolberg,

bei den Postversanddaten können Sie doch weiterhin die Festschreibung manuell unterbinden (bis zum Jahreswechsel 2017/2018).

Danach (ab 2018) stellt sich das Problem ja nicht mehr, da Postversanddaten dann ohnehin nicht mehr eingelesen werden können...

Viele Grüße

Christian Wielgoß

Re: GdOB i.V.m. ASCII-Import

Chris_Pollack — Fri, 09 Dec 2016 10:06:14 GMT

Hallo Herr Kolberg,

ich verstehe. Ihre gewünschte "undo"-Funktion soll sich auf jegliche Eingaben im Programm erstrecken. Wir nehmen den Wunsch auf. Machen Sie sich aber bitte keine großen Hoffnungen auf eine Realisierung. Ich denke nicht, dass wir eine solche Funktion mit vertretbarem Aufwand realisieren können.

Das ausblenden von Generalumkehr-Buchungen ist ebenfalls eine Ansichts-Option. Auch hier entstehen keine Buchungen.

Mit freundlichen Grüßen

Chris Pollack

Service Rechnungswesen (FIBU)

DATEV eG

Re: GdOB i.V.m. ASCII-Import

Gelöschter Nutzer — Fri, 09 Dec 2016 10:38:06 GMT

Das ausblenden von Generalumkehr-Buchungen ist ebenfalls eine Ansichts-Option. Auch hier entstehen keine Buchungen.

Die Option "Ausblenden Generalumkehr" sollte aber immer die letzte Einstellung verwenden. Es ist ziemlich frustrierend, diese Option jedesmal anzuhaken (nervig!).

Ich hoffe das kommt endlich einmal.

Gruß A. Martens

Re: GdOB i.V.m. ASCII-Import

theo — Fri, 09 Dec 2016 14:47:18 GMT

ich verstehe. Ihre gewünschte "undo"-Funktion soll sich auf jegliche Eingaben im Programm erstrecken. Wir nehmen den Wunsch auf. Machen Sie sich aber bitte keine großen Hoffnungen auf eine Realisierung. Ich denke nicht, dass wir eine solche Funktion mit vertretbarem Aufwand realisieren können.

Sollten Sie aber trotzdem drüber nachdenken, da das Industriestandard ist (Strg+z bzw. Klick).

Auf die schnelle, was den Rest anbetrifft:

- Datev zwingt mich unter gewissen Umständen, irgendwas (ggf. fehlerhaftes) festzuschreiben
- ich kann das ganz einfach aushebeln, indem ich auf Postversand verzichte u. vor dem Import bei Datev in den Textdateien rummanipuliere
- inwiefern das GoBD-konform ist, müsste mir noch erklärt werden,
genau so wie
- bei anderen Datev-eigenen Importfunktionen kann ich beliebig oft neu importieren/erzeugen/löschen u. was mir grad so einfällt, ohne irgendein Log zu erzeugen* (gestern getestet)

-> logische Schlussfolgerung: Das Programm ist an keiner Stelle eine Hilfe für GoBD, an manchen Stellen aber eine Krücke.

Dementsprechend gelten weiterhin meine ursprünglichen Aussagen zum Thema

*der Zahlungsverkehr hat mich die Tage gestresst (bei einem Bankbestand der aus manuellen Importen u. Datev-Zahlungsverkehr bestand) u. die Abhilfen haben nicht funktioniert, ergo habe ich die Banken gelöscht u. neu importiert. Auf die GoBD-rechtlichen Konsequenzen wurde ich an keiner Stelle hingewiesen, auch Logs waren nicht zu finden. @datev: Falls jemand (BP) fragt, was erklär ich dann?