Wenn man sich ein eigenes ASCII-Format erstellt, kann man dort auch ein Feld für die Festschreibung festlegen und dieses mit 0 belegen.
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. 
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.
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).
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
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
Ich stimme Ihnen ja zu. 
