Postversandformat abgekündigt

[#1]

Unsere aktuelle WaWi kann die Buchungen nur im Postversandformat exportieren. Da die Umstellung auf eine neue Warenwirtschaft bis 07/2018 dauert, ist meine Frage folgende. Können wir unser Rechnungswesen Compact V. 6.0 noch bis 07/2018 benutzen, ohne das wir Anfang des kommenden Jahres auf die Version 6.1, oder höher updaten, denn ab der Version 6.1 ist das Postversandformat von Datev abgekündigt.

[#2]

Anderer Ansatzpunkt: Mohr-IT GmbH - DaWan

Kosten überschaubar, bis jetzt keine Probleme.

Grüße

Rolf Ganter

[#3]

Auch hier gibt es eine selbst gestrickte Software, die täglich die Ausgangsrechnungen in einen Vorlauf im Postversand- Format exportiert, die dann gebündelt per USB- Stick zur Kanzlei kommen, wo diese in einem Rutsch eingelesen werden. Der Bankmanager ordnet die Zahlungen in der Kanzlei dann vollautomatisch und fehlerfrei zu.

Ein Umprogrammieren des Mandanten- Systems ist wegen des nicht mehr aktiven Programmierers völlig ausgeschlossen. Es müßte ein komplett neues System implementiert werden und nur wegen des Exportes wird das nicht geschehen und wir als Kanzlei können das auch nicht "anordnen". (Do not touch a running System)

Der WaWan scheint ja mehr als holprig zu sein, wenn mehr als ein Vorlauf, oder gar mehrere Mandantenbuchhaltungen zu bearbeiten sind. (Fehlende Mehrfachauswahl, btw. nicht mandantenfähige Ordnerstruktur).

Wie ist die offizielle Empfehlung von DATEV für unseren Fall, daß vorerfaßte Belege im Postversand- Format einzulesen sind? Das wäre doch so, als würde man beim Auto einfach von einem Tag auf den Anderen ein Handy Störsignal aktivieren, da diese Geräte ja nicht mehr während der Fahrt genutzt werden dürfen. Die "Freisprecher" schauen dann halt in die "Röhre" und Beifahrer sind dann halt Kollateralschaden.

Ein Scannen von hunderten von Papierbelagen (oder PDF- Importe) pro Monat für UO würde keinen Mehrwert bringen, sondern nur unnötiges Paoier und Fehler produzieren.

[#4]

Das Nachfolgeformat existiert schon einige Jahre und das Postversandformat ist auch schon ewig als veraltet deklariert und seither wurde die Abkündigung angekündigt.

Leider war die Kommunikation mit den Fremdsoftwarefirmen nicht so offen wie zu den eigene "Kunden". Aber auch die verspätete Information war nicht "von einem Tag auf den Anderen". Ein Jahr sollte eigentlich ausreichend sein.

[#5]

Eine Holprigkeit kann ich bei DaWan nicht feststellen. Der Konverter verrichtet klaglos seine Arbeit, man kann Profile für unterschiedlich aufgebaute Excel-/CSV-Ausgangsdateien anlegen, Postversanddateien werden rasend schnell umgewandelt usw.

Dass die Software keine Mehrfachauswahl bietet, mag vielleicht schade sein, behindert doch aber nicht bei der täglichen Arbeit, es sei denn, man hantiert mit über 30, 40 oder mehr Buchungsstapeln pro Tag.

Eine Mandanten-Ordner-Struktur sollte auch schon vor dem Einsatz vorliegen, denn die umzuwandelnden Ausgangsdateien sollten aus Dokumentationsgründen doch ohnehin gesichert werden.

In diesem Falle möchte ich wie Herr Kinzler DATEV in Schutz nehmen:

Die Thematik Postversanddaten-Format wurde lange kommuniziert und DATEV kann - schon aus Rücksicht auf die anderen Genossenschafter - nicht für jeden individuellen Fall Lösungen anbieten. Außerdem wäre es wohl sehr unverständlich, wenn einerseits das alte Format aus allen Programmen verbannt wird und andererseits eine DATEV-eigene Konverterlösung programmiert würde, welche ihrerseits entsprechend gewartet werden müsste.

Auch wenn es vielleicht hart ist, aber irgendwann musste der Schritt vollzogen werden. Nun ist es halt 2017/18 der Fall. Eine Frage: Was wäre 2018/19 anders? Oder vielleicht so gefragt: Sähe die Diskussion 2018/19 nicht genauso wie jetzt aus?

[#6]

Was nütze ein neues Format, welches alle Nas' lang geändert wird?

Da gibt es zweckentfremdete Belegfelder, neu Festschreibungskennziffern und diverse neue Felder, die man sich irgendwo aus den Datev- Hilfen heraussuchen darf. Es gibt ja nicht einmal ein Tool, mit welchem ein Programmierer überprüfen kann, ob seine Export- Datei in Ordnung ist. Natürlich könnte sich der Programmierer eine ReWe- Version kaufen... aber wollen wir das?

Niemand verlangt, daß am alten Format irgend etwas weiter entwickelt wird.

Man könnte es verstehen, wenn bei einer komplett neuen ReWe- Version alte Schnittstellen ausgelagert werden. Wobei ich erwarte, daß von DATEV ein Tool zum Import angeboten wird. (und ich meine nicht eine Einzelplatzinstallation, die ohne Update auf dem Datum 2017 gehalten wird, um auch in 2018 Vorläufe aus Postversanddaten erzeugen zu können)

Die Situation heute ist, daß manche Mandantensysteme ausschließlich das alte Format liefern können, welches seit Jahrzehnten problemlos funktionierte.

Natürlich ist ein Wechsel "hart", aber es ist nicht unsere Aufgabe als Buchhalter, dem Mandanten vorzuschreiben, wann er sein funktionierendes Warenwirtschaftssystem in die Tonne treten soll. Natürlich... Wir können warnen und empfehlen, aber wenn der Mandant sich entscheidet, dann müssen wir mit dem arbeiten, was wir bekommen. Eine Verschlechterung unserer Dienstleistung bei gleichzeitiger Gebührenerhöhung zum Jahreswechsel läßt sich bei gleichbleibendem Input nicht vermitteln.

Frage an DATEV eG: "Was machen?" (Mandat kündigen?)

[#7]

Es gibt ja nicht einmal ein Tool, mit welchem ein Programmierer überprüfen kann, ob seine Export- Datei in Ordnung ist. Natürlich könnte sich der Programmierer eine ReWe- Version kaufen... aber wollen wir das?

Doch. Leider ist dieses kostenpflichtig ( https://www.datev.de/web/de/datev-shop/betriebliches-rechnungswesen/schnittstellen-entwicklungsleitfaden-fuer-das-datev-… ).

Dies war es auch schon für das alte Postversand-Format (DATEV Self).

[#8]

Ein Jahr sollte eigentlich ausreichend sein.

Mich interessiert mal eine technische Begründung, warum man ein funktionierendes Format - selbst wenn man es nicht mehr weiterentwickelt - unbedingt aus der Software entfernen muss.

Aus meiner (laienhaften) Betrachtungsweise ergibt sich dafür keinerlei Notwendigkeit. S. bspw. MS/Libre/Open-Offices. Dort werden immer mehr Formate u. auch sämtliche ehemaligen unterstützt.

PS Macht noch ein paar mehr Threads zu dem Thema auf, dann haben wir hier den Überblick.

[#9]

PS Macht noch ein paar mehr Threads zu dem Thema auf, dann haben wir hier den Überblick.

Das Thema wird bestimmt noch akuter, da viele noch nicht wissen (werden), warum die Fremddaten für Januar 2018 nicht eingelesen werden können. Und Fremdsoftwarehersteller kümmern sich da mit unterschiedlicher Priorität darum.....

[#10]

Nur weil bei Datev u. allen die da dranhängen Chaos herrscht, heisst das nicht, dass wir hier auch Chaos haben müssen..

Die Moderation ist ja sonst immer zur Stelle (Netiquette, Werbung etc. u.a.). Könnte zumindest taggen, wenn nicht zusammenführen. Edit von unzureichenden Titeln, bspw. fehlende Angabe Lodas od. LuG sollte ja wohl drin sein.........

[#11]

Das Thema wird bestimmt noch akuter, da viele noch nicht wissen (werden), warum die Fremddaten für Januar 2018 nicht eingelesen werden können. Und Fremdsoftwarehersteller kümmern sich da mit unterschiedlicher Priorität darum.....

An der mangelnden Information seitens der DATEV kann das dann auch nicht liegen.

Es ist auch eher ein Problem der (mangelden?) Bereitschaft der Fremdsoftwareherstellern.

(Die DATEV trifft natürlich auch einen Mitschuld, man hätte zu dem Zeitpunkt, andem man die Genossen informiert hat auch gleich die Informationen an die Lizenznehmer der SELF-Schnittstelle richten können und nicht erst 2 Jahre später).

Manch Hersteller hat möglicherweise die Schnittstelle auch nicht lizensiert gehabt und diese ohne die Doku implementiert; die SELF-ID wurde scheinbar nicht überprüft).

Im Rewe-Zusatzmodul "Anwendungsinfo" kann man sich betroffene Fälle anzeigen lassen:

[#12]

Ich kann nicht beurteilen, welche Informationspolitik DATEV bei Fremdherstellern betrieben hat. Allerdings musste auch früher schon die SELF-Schnittstelle lizenziert werden, so dass die meisten Dritthersteller, vor allem die großen, zumindestens Zugriff auf Informationen gehabt haben müssen. Wenn dort natürlich die entsprechenden Dokumente nicht gelesen und umgesetzt werden oder evtl. ein sicherlich wichtiger Mail- oder Sonstwas-Verteiler abbestellt wird, ist das ein Armutszeugnis für den Entwickler.

Ob die Umsetzung des neuen DATEV-Formates gelungen ist oder nicht, kann sicherlich diskutiert werden. Da aber durch gesetzliche Vorgaben (siehe nur Stichwort GoDB - Festschreibung) auch das alte Format hätte weiterentwickelt werden müssen (SELF-Schnittstelle), hat sich DATEV in Hinsicht auf die Zukunftsfähigkeit für ein nicht binäres, universell einsetzbares, plattformübergreifendes Format entschieden und das schon vor einiger Zeit.

Es gab und gibt auch bei dem alten Postversanddaten-Format schlechte Implementierungen (Lexware: fehlender Buchungsschlüssel 7% Vorsteuer, SAGE: vollkommen überfordert bei der Konvertierung von Sammelbuchungen, Avista: Export von Nettobuchungen, wenn Nettobetrag zzgl. USt um einen Cent vom Brutto abweichen etc.), sei es durch den Programmhersteller oder SELF. Ich glaube, dass DATEV hier zu einem Ende kommen wollte, weil Aufwand für die Betreuung derlei Unsäglichkeiten recht hoch sein wird.

Eine DATEV-CSV-Datei kann man zur Not auch aus einer normalen Excel-Datei hinbekommen. Die meisten Drittprogramme könn(t)en in CSV exportieren, ohne noch eine zusätzliche, proprietäre Schnittstellenlösung zu lizenzieren und zu implementieren.

Was DATEV natürlich auch über die Systempartner- und Softwarehersteller hinaus kommunizieren muss, ist der Zeitpunkt, zu welchem sich das neue DATEV-Format ändert. Die frühere Version 3.00 wurde Anfang 2017 von der Version 5.10 abgelöst (u. a. wegen des Festschreibekennzeichens). Leider wurde dieser Versionswechsel auch beim Abruf von Lohnbuchungen aus dem RZ umgesetzt, so dass der Mandant die Lohnbuchungen nicht mehr in sein Drittprogramm einlesen konnte. Wäre diese Information schon Ende 2016 bekannt gewesen, hätte man Vorkehrungen treffen können.

[#13]

Auch ich kann im Wegkicken des uralten Standards keinen Grund sehen.

Allein aus Datenschutzgründen kann ich keine Begeisterung am neuen Format finden.

Die CSV- Datei wird im Klartext transportiert (unverschlüsselte Email aus dem Kassen und Warensystem (Excel- Kasse) ) und ist dann per Doppeltklick für jeden Anwender per Excel zu öffnen, so daß trotz Festschreibe- Kennzeichen der Vorlauf bearbeitet werden kann.

(Zwei Verstöße gegen die Grundsätze)

Wem ist es bereits gelungen, Werte im alten Postversand ohne spezielle Hilfsmittel (DATEV- Software) einzusehen, auszuwerten oder gar zu ändern? Ein unbekannter Dritter, der zufällig in den Besitz der Mail kommt, hat ohne DATEV- Kenntnisse keine Chance, den Inhalt des Kassenbuches lesbar zu machen.
Dieses Uralt- binär- System ist und bleibt für den Transport Klasse!
Nach dem Import ist das möglich, aber damit ändert sich das Herkunftszeichen der Zeile, so daß jede Änderung nachvollziehbar bleibt.

[#14]

Da aber durch gesetzliche Vorgaben (siehe nur Stichwort GoDB - Festschreibung) auch das alte Format hätte weiterentwickelt werden müssen (SELF-Schnittstelle)

Inwiefern bedingen die GoBD eine Weiterententwicklung des Formats?

[…] hat sich DATEV in Hinsicht auf die Zukunftsfähigkeit für ein nicht binäres, universell einsetzbares, plattformübergreifendes Format entschieden und das schon vor einiger Zeit.

Das ist loeblich, eine bessere Wahl als txt, ggf. in Kombination mit pdf, haette ich auch nicht getroffen.

   Allerdings wird

- das vorherige Format unvollstaendig umgesetzt

- laufend veraendert

- die Dokumentation dafuer kostet EUR 280 (inkl. Updates??)

Eine DATEV-CSV-Datei kann man zur Not auch aus einer normalen Excel-Datei hinbekommen. Die meisten Drittprogramme könn(t)en in CSV exportieren, ohne noch eine zusätzliche, proprietäre Schnittstellenlösung zu lizenzieren und zu implementieren.

Sollten eigentlich alle Programme, die an Internet oder BRD/EU-Dǜ-Verfahren teilnehmen wollen koennen. Z.B. fuer ne ZM (erstes Sem. Perl).

Was DATEV natürlich auch über die Systempartner- und Softwarehersteller hinaus kommunizieren muss, ist der Zeitpunkt, zu welchem sich das neue DATEV-Format ändert.

Was in Zeiten der Digitalisierung nicht schwierig ist. Bspw. die BfinVerw macht sowas online (unentgeltlich/Top-Quali).

[#15]

Allein aus Datenschutzgründen kann ich keine Begeisterung am neuen Format finden. Die CSV- Datei wird im Klartext transportiert (unverschlüsselte Email

Das sind mind. 2 verschiedene Formate/Protokolle. Mit Transport-Encryption (end2end, bspw. Whatsapp) die ich wirklich jedem ans Herz lege (u. auch Protokolliere) noch ein paar mehr 

[#16]

Zwei Anmerkungen:

- GoDB - Festschreibung

Wie kann ich einen fehlerhaften Vorlauf "reparieren"

Wenn der Unfall passiert ist, muß - sofern eingerichtet - einfach der Mandant aus dem Zweitdatenpfad, der das Backup vom Vortag beinhaltet in den Produktiv- Datenpfad einkopiert werden (Storno der Festschreibung). Anschließend wird der per Excel umgestrickte Vorlauf erneut als "vom Vorsystem unveränderlich" übernommen. Im Aktivitätenprotokoll ist nichts von dieser Manipulation sichtbar.

Früher änderte man einfach den Buchungssatz und man hatte hier ein "RE" im später festgeschriebenen Vorlauf stehen. Im Aktivitätenprotokoll wird alles exakt dokumentiert.

- Email (Transport-Encryption, usw.)

Sicherlich gibt es diverse "sichere Übertragungswege", aber was nützt die "sichere Übertragung", wenn die Email einen verkehrten Empfänger erreicht.

"verschiedene Formate / Protokolle" ... Solange die DATEV- Excel- Kasse und vermutlich auch der Nachfolger die CSV- Datei unverschlüsselt per Email versendet, haben wir die für jedermann lesbare Postkarte. Natürlich kann man da Dinge einrichten... Aber als Steuerkanzlei sind wir nicht befugt, Mandantensysteme für lau mal schnell auf das Niveau der EU- Datenschutz- Grundversorgung zu heben.

- Fazit:

Früher konnte ein Empfänger von fehlgeleiteten Postversanddateien (verlorener USB- Stick) aufgrund des unverständlichen Binärcodes nichts mit den Daten anfangen, während beim neuen Format alles mit einem Doppeltklick in Excel sichtbar wird.

[#17]

Hallo,

Inwiefern bedingen die GoBD eine Weiterententwicklung des Formats?

Weil es in der alten Schnittstelle z. B. die Funktionalität des Festschreibekennzeichens schlichtweg nicht gab. Es hätte also einer Implementierung seitens DATEV bedurft und da sich die Genossenschaft auf das neue Format eingegroovt hat, hat man vermutlich diese gesetzliche Vorgabe genutzt, das alte SELF so schnell wie möglich zu begraben.

Allerdings wird

- das vorherige Format unvollstaendig umgesetzt

- laufend veraendert

- die Dokumentation dafuer kostet EUR 280 (inkl. Updates??)

Über die Umsetzung ist sicherlich zu sprechen, laufende Veränderungen kann ich bis auf den von mir geschilderten ärglichen Wechsel von 3.00 auf 5.10 nicht erkennen.

Dass die Doku einen happigen Preis hat, wurde ja schon oft bemängelt. Persönlich glaube ich, dass DATEV damit den "ambitionierten Frickler" davon abhalten will, zu tief in die Materie einzudringen.

Womit ich bei Herrn Kolberg wäre. Ich gebe Ihnen Recht, dass CSV-Dateien naturgemäß manipulierbar sind. Wer das Wissen hat, in welcher Zelle der "geheimnisumwitterten" Zeile 1 des neuen Formats eine 1 oder 0 über die Festschreibung entscheidet, kann sicherlich noch andere Dinge anstellen.

Und dass selbst die Umsetzung des IRW (Integriertes Rechnungswesen) noch immer nicht komplett manipulationssicher ist, zeigt ihr Beispiel und das wissen hoffentlich auch die DATEV-Verantwortlichen, der EDV-Versierte in der Kanzlei weiß es jedenfalls. (Die meisten Mitarbeiter in den Büros verfügen aber nicht über das Wissen.)

Der zu betreibende Aufwand ist allerdings nicht einfach mit einem Knopfdruck zu erledigen und setzt einen Vorsatz voraus. Fraglich dürfte deshalb sein, wer da freiwillig den Kopf in die Schlinge legt ...

Für die Absicherung des Transportweges einer oder mehrerer Dateien ist ohnehin immer der Absender verantwortlich. Sicherlich, DATEV macht es sich etwas einfach, den Normalnutzer in der Sicherheit zu wiegen, dass bei einem Versand alles datenschutzrechtlich iO ist, denn das, was hier besprochen wird geht ja über das Basiswissen weit hinaus, aber das ist der unschöne Lauf der Dinge.

Dem Trend, Verantwortlichkeiten, daraus resultierende Haftungen, Mehrarbeiten im Allgemeinen auf den Lohnabrechner bzw. Buchhalter (vulgo Steuerberater) abzuladen verschließt sich DATEV leider nicht.

[#18]

- Email (Transport-Encryption, usw.)

Sicherlich gibt es diverse "sichere Übertragungswege", aber was nützt die "sichere Übertragung", wenn die Email einen verkehrten Empfänger erreicht.

Das ist doch der Sinn einer end2end-Verschluesselung*: Nur der legitime Empfaenger kann sie oeffnen

- Fazit:

Früher konnte ein Empfänger von fehlgeleiteten Postversanddateien (verlorener USB- Stick) aufgrund des unverständlichen Binärcodes nichts mit den Daten anfangen, während beim neuen Format alles mit einem Doppeltklick in Excel sichtbar wird.

Dem ist sicher nicht so. Da Datev PV ein weitverbreitetes Format mit zugaenglicher Dokumentation ist, ist davon auszugehen dass

- div. Fremdprogramme den Import beherrschen
- jemand der einer unverschluesselten Mail mit PV-Daten habhaft wird, sie mit etwas Recherche auch einlesen kann

*im Datev-Umfeld S/MIME, weiter verbreitet pgp u. out of the box m.W. nur Whatsapp u. mittlerweile auch der fb-messenger