Schnittstellenformat "Postversand-/ASCII-WIN-Importe" eingestellt!

[#1]

Hallo,

in der Diskussion geht es hauptsächlich um die drei Importformate DATEV-Format, Postversandformat und die Bisherigen Rechnungswesen-Formate (ASCII). Daher möchte ich hier noch einmal unterschieden und um ggf. neue Informationen ergänzen.

DATEV-Format

Dies ist das neue Standardformat für den Import und kann jederzeit in Kanzlei-Rechnungswesen eingelesen werden.

Ab der Programmversion 6.0 (DVD 11.0, Auslieferung voraussichtlich Ende August) können auch Belegstapel für das Buchen elektronischer Belege über DATEV-Format importiert werden.

Damit können auch bei der Kassen- und Warenerfassung für Office die Belegstapel im DATEV-Format übergeben werden.

Voraussetzung: Kassen- und Warenerfassung für Office ab Version 3.1

Postversandformat

Dieses Format wird zum Jahresende eingestellt. Ein Import wird dann nicht mehr möglich sein.

Die Hersteller von Fremdprogrammen müssen bis dahin auf DATEV-Format (oder ASCII-Format) umstellen.

Bisherige Rechnungswesen-Formate (ASCII)

Auch die Bisherigen-Rechnungswesen-Formate aus der Zeit vor DATEV pro werden zum Jahresende eingestellt.

Für diese Formate wird es in der Programmversion 6.0 eine Konvertierungsmöglichkeit in die aktuellen ASCII-Formate geben.

Ausnahmen: Die Importformate der Geschäftspartner-Stammdaten (Debitoren/Kreditoren) und die Exportformate für Offene Posten können nicht konvertiert werden.

So wird die Konvertierung ablaufen:

In der Formatauswahl Rechtsklick auf das zu konvertierende Format und im Kontextmenü den Eintrag Konvertieren wählen. Fertig.

Bei den aktuellen ASCII-Formaten ändert sich nichts.

Mit freundlichen Grüßen

Chris Pollack

Service Rechnungswesen (FIBU)

DATEV eG

[#2]

Sehr geehrter Herr Pollack,

es ist schön, dass sich DATEV nun zu diesem Thema geäußert hat. Die Antwort auf eine Frage sind Sie jedoch schuldig geblieben.

Wenn ich heute im Kanzlei-Rechnungswesen pro V.5.33 über Bestand -> Exportieren -> ASCII-Daten einen Vorlauf exportiere wird dieser Stapel im Format der bisherigen Rechnungswese-Formate aus der Zeit vor DATEV pro generiert (eindeutiges Merkmal: das Soll-/Haben-Kennzeichen wird in einer eigen Spalte angezeigt).

Diese Daten bekomme ich jedoch über die aktuellen ASCII-Formate nicht eingespielt. In den aktuellen ASCII-Formaten gibt es bisher kein Soll-Haben-Kennzeichen sondern lediglich ein +/- Kennzeichen.

Wird denn nun die Funktion "Exportieren -> ASCII-Daten" mit der neuen Programmversion angepasst oder werden weiterhin alte ASCII-Daten erzeugt, die beim Einspielen erst wieder konvertiert werden müssen. Das wäre vom Handling umständlicher.

Es würde auch wenig Sinn machen, wenn man die aus dem eigen Programm exportierten Daten vor dem Einspielen konvertieren müsste. Aber wenn man die Diskussionen verfolgt, geht es ja bei der DATEV anscheinend nicht immer um die Nutzerfreundlichkeit.

[#3]

Hallo Herr Krumbholz,

im Standardformat sind Umsatz und Soll-Haben-Kennzeichen unterschiedliche Felder.

Wenn Sie ein individuelles Format anlegen, können Sie auch in den aktuellen ASCII-Formaten Umsatz mit Soll-Haben-Kennzeichen in einem Feld ausgeben. Über die Feldformatierung legen Sie fest ob das Soll-Haben-Kennzeichen als S/H oder +/- entweder vor oder nach dem Betrag ausgewiesen wird.

Sie werden daher die Konvertierug ab Kanzlei-Rechnungswesen 6.0 nutzen können. Umsatz und Soll-Haben-Kennzeichen werden richtig umgesetzt.

Mit freundlichen Grüßen

Chris Pollack

Service Rechnungswesen (FIBU)

DATEV eG

[#4]

DATEV-Format

Ab der Programmversion 6.0 (DVD 11.0, Auslieferung voraussichtlich Ende August) können auch Belegstapel für das Buchen elektronischer Belege über DATEV-Format importiert werden.

Damit können auch bei der Kassen- und Warenerfassung für Office die Belegstapel im DATEV-Format übergeben werden.

Voraussetzung: Kassen- und Warenerfassung für Office ab Version 3.1

Postversandformat

Dieses Format wird zum Jahresende eingestellt. Ein Import wird dann nicht mehr möglich sein.

Die Hersteller von Fremdprogrammen müssen bis dahin auf DATEV-Format (oder ASCII-Format) umstellen.

Sehr geehrter Herr Pollack,

Viele Mandanten nutzen die DATEV- Kasse; mit einer Version, die sie irgendwann einmal zugeschickt bekommen haben, also nicht unbedingt die Version 3.1. Wir können anhand der übermittelten Daten nicht erkennen welche Version der Mandant nutzt und ob der PC überhaupt in der Lage wäre, die Version 3.1 zu nutzen..

Vor Jahren wollten wir auf das damals neue DATEV- Format umstellen, mußten aber zurückrudern, weil das automatische Buchen per Lerndatei nicht funktionierte.

Jetzt haben wir die Situation:
- "Voraussichtlich Ende August" (also nach den Sommerferien) können wir schrittweise mit der Umstellung der Kasse beginnen.(Testphase, Hausinterne Schulung, Mandanten umstellen...)

- Sicherlich wird ab Januar der Import des alten Formates nicht mehr funktionieren.

Frage: Weshalb diese Eile beim Abschalten das alten Standards, wenn selbst die DATEV- eigenen Programme heute noch auf das alte Format angewiesen sind?

Ein gut kommunizierbarer Weg wäre, wenn wir für unsere Mandanten eine neue Kassensoftware (klein, Schlank und wirklich funktionierend; auch auf Alt- Excel) bekommen würden, die dann ohne Zutun ab dem Januar 2018 das richtige Format erstellt.
(Bitte als Download- Link, so daß das auch auf PC ohne DVD- Laufwerk installierbar ist)

So können wir frühestens im September mit der Umstellung beginnen, und ob die Mandanten  dann wirklich bis zur Dezember- Buchhaltung (also mitten im Jahr) die Umstellung schaffen?

Weshalb kann das Postversand- Format nicht einfach behalten werden?

Was ist die technische Notwendigkeit, dieses, heute noch als Standard vorgelegte Import- Format übereilt herauszukicken?

PS:
Einer der ganz großen Vorteile der alten Postversanddaten besteht aufgrund der Binärform in seiner Unveränderlichkeit. Ein DATEV- Export läßt sich von Jedermann in Excel öffnen, ändern und wieder speichern, ohne daß man diese Manipulation später erkennen kann. So kann die komplette "Festschreibung" der Kasse mit Bordmitteln umgangen werden. Gibt es zu dieser Problematik bereits Lösungsansätze, wie eine Prüfsumme, die dem Kanzlei- Mitarbeiter mitteilt (und im Aktivitätenprotokoll festhält), daß er einen manuell überarbeiteten Export einspielt?

[#5]

Moin, moin,

es ist schön zu lesen, daß es demnächst ein Konvertierungstool für die alten ASCII-Lösungen geben soll, wir haben davon einige eingerichtet.

Gestern auf dem Thementag Rewe in Kiel hieß es noch: Es sind durchweg neue ASCII-Lösungen zu "stricken", nicht einmal eine Kopie der alten würde als Vorlage für eine Ergänzung möglich sein.

Ich wäre sehr froh, wenn die Umschreibung praktisch auf Knopfdruck erfolgen könnte. Ich möchte mich mehr mit dem Inhalt der Daten als der technischen Umsetzung (oder Wieder-Neu-Erstellung) beschäftigen müssen, das kann die DATEV sicher schneller und sicherer.

Allerdings verstehe ich immer noch nicht die Notwendigkeit, die alten Wege abzuschalten. GoBD können StB sicher individuell beurteilen, wahrscheinlich besser als die Programmentwickler der DATEV.

Ein schönes Wochenende in die Runde

WF

PS.: Auf die Frage, warum gibt es diese und keine andere Lösung (ich kann nicht mehr sicher sagen, ob genau zu dem hier diskutierten Stoff)  gebe, hieß es gestern mehrfach: Die Entwickler hätten das so vorgegeben. M. E. n. ist die DATEV und sind noch mehr die Entwickler Dienstleister der Genossen und damit des Berufsstandes. Manchmal beschleicht mich aber das Gefühl, daß ich dies einseitig sehen könnte.

[#6]

Hallo Herr Nahr,

um mein Anliegen zu konkretisieren ...

Ich arbeite beim Hersteller des Fremdsystems und habe die Aufgabe, unsere Schnittstelle vom Postversand-Format umzustellen auf ein Format, das mit der neuen Datev-Software kompatibel ist.

Dabei handelt es sich lediglich um die Schnittstelle (Übergabe) von Ausgangsrechnungen/Ausgangsgutschriften aus dem Verkaufsmodul unseres ERP/PPS-Systems (Datev-Format OBE). Und die Übergabe umfasst auch nur wenige (elementare) Werte.

Die letzten Anpassungen in unserer Schnittstelle waren in 2006/2008 notwendig.

Damals hatte ich problemlos Kontakt zu Datev aufnehmen können, habe den Entwicklungsleitfaden kostenlos zugesendet bekommen und konnte die nach der Anpassung erstellten Übergabedateien an Datev zur Prüfung senden (ebenfalls kostenfrei).

Aktuell stellt sich mir die Situation so dar, dass eine Unterstützung seitens Datev wohl nicht erfolgen kann/wird.

• Statt dessen muss erstmal der Entwicklungsleitfaden käuflich erworben werden - ohne genau zu wissen, ob und in welchem Umfang dieser für die o.g. Anpassung überhaupt hilfreich sein wird.
  Ich habe hier bereits gelesen, dass der Entwicklungsleitfaden z.B. keine Beispieldateien enthält, anhand derer das Ergebnis zumindest "in der Theorie" geprüft/verifiziert werden kann.
• Die notwendige Prüfung des Ergebnisses in Form der neuen Übergabedateien wird dann wohl auch "live" auf dem Kundensystem erfolgen müssen.

Sollte eine Unterstützung für uns seitens Datev doch möglich sein, so bitte ich um Kontaktaufnahme, damit wir uns über Kosten und Umfang absprechen können.

MfG

Ragnhild Schäfer

[#7]

Hallo Frau Schäfer,

bitte wenden Sie sich hierzu schriftlich an die Kollegen der Schnittstellenberatung.

Email: schnittstellenberatung@datev.de

Vielen Dank und ein schönes Wochenende.

Mit freundlichen Grüßen

Christian Nahr

Service Rechnungswesen (FIBU)

DATEV eG

[#8]

Vielen Dank, das werde ich tun.

Ihnen auch ein schönes Wochenende.

[#9]

Bezeichnend diese Website
https://www.datev.de/web/de/service/antworten-finden/schnittstellen/aenderungen-zum-jahreswechsel-20162017/

Die "Hintergrundinformationen" sind völlig aussagelos.

Die "Verbesserungen" sind für die Praxis m.E. irrelevant:

Buchungstext: Alle Kassenmandanten haben sich auf die beschränkungen eingestellt u. arbeiten mit 30 Zeichen. Warum man statt 30 nun 60 Zeichen anstatt unbeschränkter Zeichenzahl einführt, bleibt ein Geheimnis. (@datev Antwort erwünscht)

Unterscheidung zw. nat. Person u. Unternehmen/Vereinigung macht für das Mahnwesen keinen Unterschied u. ist auch sonst eher hinderlich. Lasse mich gern eines besseren belehren.

§ 13b hätte man wahrscheinlich mit wenig Aufwand in das alte Format einfügen können. Ich kenne hier allerdings auch keinen praxisrelevanten Fall.

Verschwiegen wird, dass Kontroll-/Abstimmsummen mit dem neuen Format nicht mehr möglich sind - eine eklatante Verschlechterung des alten Formats.

epicfail​

[#10]

Hallo theo,

Bei der Einführung von DATEV Pro und des damit verbundenden DATEV-Formats wurden auch viele Anwenderwünsche berücksichtigt. Unter anderem war auch die Erweiterung des Buchungstextes auf 60 Zeichen ein häufig gestellter Wunsch. In der Praxis wird diese Erweiterung von unseren Kunden sehr häufig genutzt.

Eine Beschränkung der Zeichenzahl bei Daten-Feldern ergibt sich grundsätzlich aus technischer Sicht und ist auch aus Performance-Gründen geboten. Zudem spiegeln die uns vorliegenden Anwenderwünsche derzeit keinen Bedarf für eine Erweiterung wider.

Mit freundlichem Gruß,

DATEV eG

Selina Gottwald

Programmservice Rechnungswesen (FIBU)

[#11]

Hallo Herr Pollack,

"...Exportformate für Offene Posten können nicht konvertiert werden."

bedeutet, dass für "Geschäftspartner (Offene Posten)" (s.u.) ein individuelles ASCII-Format erstellt werden muss. Oder gibt es noch eine andere Möglichkeit?

[#12]

Hallo Frau Gottwald,

zum Thema "Belegfeldlänge und -inhalt" gab es m.E. eine ganze Menge Wünsche zur Verlängerung des Feldes und zur Verwendung von Sonderzeichen, die in empfangenen Rechnungen enthalten sind oder aus einen Fakturiersystem übernommen werden sollen.

Schöne Grüße

Willi Müller

[#13]

Hallo Herr Buschhold,

der Hintergrund warum sich Geschäftspartner nicht konvertieren lassen liegt darin, dass einige Datenfelder der Debitoren-/Kreditorenstammdaten sich mit DATEV pro geändert haben und daher nicht eindeutig den neuen Feldern zugeordnet werden können.

Im Fall der Geschäftspartner (Offene Posten) funktioniert eine Konvertierung, aber das Format muss ggf. nachträglich angepasst werden. Konkret werden wir überall dort, wo ein geändertes Feld in dem Format ausgewählt ist, ein Leerfeld übergeben. Das betrifft vor allem die alten Felder Name 1 und Name 2.

Die reinen Wertefelder aus der OPOS-Liste werden konvertiert. Das Standardformat aus Ihrem Screenshot wird vollständig konvertiert, da hier keine Felder der Geschäftspartner-Stammdaten enthalten sind.

Hallo Herr Müller,

Frau Gottwald hat sich in ihrer Antwort nur auf das Feld Buchungstext bezogen.

Mit freundlichen Grüßen

Chris Pollack

Service Rechnungswesen (FIBU)

DATEV eG

[#14]

Hallo Frau Gottwald,

das ist mir ein wenig zu un-technisch (aus Laiensicht).

Bei der Einführung von DATEV Pro und des damit verbundenden DATEV-Formats wurden auch viele Anwenderwünsche berücksichtigt. Unter anderem war auch die Erweiterung des Buchungstextes auf 60 Zeichen ein häufig gestellter Wunsch.

kann ich irgendwie nicht glauben. Ich würde annehmen, User machen Vorschläge wie "der Text ist zu kurz u. müsste länger sein" u. nicht "wir haben 30 Zeichen brauchen aber genau 60"*.

Eine Beschränkung der Zeichenzahl bei Daten-Feldern ergibt sich grundsätzlich aus technischer Sicht und ist auch aus Performance-Gründen geboten.

Begründungen aus 'technischer Sicht' u. aus 'Performance-Gründen' ohne weitere Erläuterungen sind eigentlich ein Fall fürs Phrasenschwein**

Die 'technische' Begründung wäre interessant. Macht es wirklich einen Unterschied, ob ich ein Format mit beliebigen Feldlängen hab oder eins mit beschränkten? Unter der Annahme, dass User wahrscheinlich selten Romane in den Text schreiben u. meistens unter 60 Zeichen bleiben?

* Letzteres wäre wahrscheinlich als Suggestivfrage/MultipleChoice-Ergebnis möglich.

** https://de.wikipedia.org/wiki/Doppelpass_(Fernsehsendung)

[#15]

Ich glaube, daß jeder, der die Postversanddaten nutzen muß, das Problem der 60 Zeichen ganz hinten anstellen wird. Das sind meistens Kleinunternehmer, die ihr Uralt- PC- Programm weiter nutzen wollen. Dann gibt es natürlich noch die Mandanten, die vor Ewigkeiten Ihre eigene Systeme entwickelten, die noch heute zuverlässig die Postversand- Daten produzieren.... und dann natürlich noch die DATEV- Excel- Kasse, deren DATEV- Format bis heute nicht per Lerndatei verarbeitbar ist.

Ich kann keinen technischen Grund erkennen, weshalb dieses Format jetzt über Bord geschmssen werden muß, Bei einem echten DATEV- Upgrade (DATEV- Pro- Nachfolger -> DATEV- Adv (für advanced) ) müssen natürlich diese alten Zöpfe fallen und durch Konvertieirungs- Tppls ersetzt werden.

aber... die Entscheidungen sid wohl längst gefalle... dahr mein

Wunsch: DATEV bietet ein kostelnloses Konvertierungs- Tool an, mit folgenden Eigenschaften:

- Einfachste Bedienung (Drad & Drop)

- Vorschau und Editiermöglichkeit der Kopfzeilen

- Aktionen werden protokolliert und Voräufe werden gespeichert

- Mandanten- spezifische Übersicht mit importerten bzw. generierten Vorläufen,

- Der Import nach ReWe erfolgt mit "SV"- Kennzeichung

Eine Umstellung des "Buchungstextes" auf variable Feldlänge halte ich aus meiner laienhaften Sicht der heutigen DATEV- Software für technisch nicht realisierbar. Hierfür gibt es mittlerweile zu viele interne Schnittstellen, so daß eigentlich alles umprogrammiert werden müßte. Dazu kommen dann noch die Fremdprogramme, die ohne Änderung maximal 60 Zeichen importieren können.

[#16]

Diesen Wunsch kann ich nur unterstützen.

Die DATEV sagt, dass der Support angerufen werden soll, falls Daten weder mit dem DATEV-Format noch mit dem neuen ASCII eingespielt werden können. Hat jemand noch Infos, ob es doch eine "Hintertür" gibt, um Postversanddateien einzuspielen?

[#17]

Hallo Herr Behrens,

vorraussichtlich ab der DVD 11.1 können Abstimmsummen, die gegen das Konto 9800 gebucht wurden, auch im DATEV-Format importiert werden.

Mit freundlichen Grüßen

Christian Nahr

Service Rechnungswesen (FIBU)

DATEV eG

[#18]

Beitrag gelöscht von @Schoenweiss Katharina

Grund: Verstoß gegen die @Netiquette - unerwünschte Werbung

[#19]

Beitrag gelöscht von @Schoenweiss Katharina

Grund: Verstoß gegen die @Netiquette - unerwünschte Werbung

[#20]

Hallo Herr Behrens,

vorraussichtlich ab der DVD 11.1 können Abstimmsummen, die gegen das Konto 9800 gebucht wurden, auch im DATEV-Format importiert werden.

Mit freundlichen Grüßen

Christian Nahr

Service Rechnungswesen (FIBU)

DATEV eG

Und wie ist es mit exportierten Primanotas?

Wie werden da die Zwischen- u. Gruppensummen behandelt?

DATEV ist ja bis heute nicht in der Lage, einen einwandfrei funktionierenden Assistenten für eine Suche- u. Ersetzenfunktion bereitzustellen und verweißt hierzu immer auf den Excel-Export, was übrigens eine ganz schwache und geradezu peinliche Grundeinstellung von DATEV ist. Das nur nebenbei.

Aber was ist nun mit den Primanota-Exporten und den Zwischen- u. Gruppensummen?

Gruß A. Martens

[#21]

Hallo Herr Martens,

beim Exportieren von DATEV- und ASCII-Format werden die Zwischen- und Gruppensummen aktuell nicht mit exportiert.

Es existiert bereits der Wunsch, jedoch können wir aktuell keinen Umsetzungszeitpunkt nennen. Wir werden den Wunsch erneut aufnehmen und an die zuständige Fachabteilung weitergeben.

Mit freundlichen Grüßen

DATEV eG

Selina Gottwald

Programmservice Rechnungswesen (FIBU)

[#22]

Die Frage ist, warum werden diese nicht ex- u. importiert(*)!

Das es nicht geht, dass ist mir schon klar.

------

* Mehrfachnennung sind möglich:

• Ignoranz
• Unfähigkeit
• Unwissendheit
• Überarbeitung
• Priorität
• von Anwendern nicht gewünscht
• kein qualifiziertes Personal
• wird demnächst umgesetzt (kurfr. zurückgestellt)
• keine Umsetzung möglich (Programmcode/Inkombatibilität)
• man kann dafür keine Gebühren erhöhen
• .....

Gruß A. Martens

[#23]

Es fehlt noch der entscheidende Punkt:

"Recherchen bei befragten Anwendern haben ergeben, dass dieser Anforderung keine Relevant beigemessen wird".

[#24]

Hallo,

die erfassten Gruppen- und Abstimmsummen im Buchungsstapel stellen keine Buchungssätze dar.

So lang der Stapel nicht festgeschrieben ist, können sie beliebig gesetzt, geändert und gelöscht werden.

Gruppen- und Abstimmsummen werden errechnet, sie passen sich mit jeder neuen/geänderten Buchung an.

Sie helfen bei der Strukturierung der Primanota eines Buchungsstapels und der Kontrolle der erfassten Umsätze.

Diese Gruppen- und Abstimmsummen erfüllen bzw. ersetzen nicht die Belegfunktion der Einzelbuchungssätze für die Nachvollziehbarkeit i.S.d. GoBD.

In der Auswertung Primanota sind diese Summen enthalten und bleiben auch nach der Festschreibung des Buchungsstapels erhalten. Sie können bei Bedarf die Primanota inkl. Summen drucken oder bspw. in Excel ausgegeben.

Beim Export/Import von Bewegungsdaten (Buchungsstapel) im DATEV-Format oder ASCII-Format werden Einzelbuchungssätze exportiert bzw. importiert. Für die Summen gibt es keine Buchungssätze, es handelt sich ja um errechnete Werte.

Mit freundlichen Grüßen

Angelika Roßmeisl

Service Rechnungswesen (FIBU)

DATEV eG

[#25]

Postversandformat zu DATEV Format

Guten Tag,

eine einfache Lösung finden Sie hier: 

auf der Website unter

  http://www.planprosaas.com/

Ich habe es getestet. Die Umsetzung läuft schnell und fehlerfrei. Auch der Support bei Problemen lief telefonisch und innerhalb weniger Minuten.

Harzliche Grüße

Franz Knoop

[#26]

eine einfache Lösung finden Sie hier

[#27]

Beitrag gelöscht von @Marco Lachmann

Grund: Verstoß gegen die @Netiquette - unerwünschte Werbung

[#28]

Beitrag gelöscht von @Marco Lachmann

Grund: Verstoß gegen die @Netiquette - unerwünschte Werbung

[#29]

Wir hoffen Diese Information hilft Ihnen weiter.

Entscheiden Sie selbst.

[#30]

Sehr geehrter Herr Behrens,

da es sich um eine Lösung für die DACH Region handelt, wird diese auf der Website für unsere englischsprachige Kundschaft nicht gesondert beworben.

Würde man auf der englischspachigen Seite allerdings auf den Lizenzshop Link gehen, so würde man ebenfalls die Informationen zu dem Postversandformat Modul finden.