KEINE SONSTIGE NACHRICHT BEI ZU LANGEM NAMEN!

[#1]

Sehr geehrte Damen und Herren der DATEV,

heute morgen wollte ich eine Sonstige Nachricht an das Finanzamt senden. Hierbei teilte mir das Programm mit "Speicher nicht erfolgreich. Bitte versuchen Sie es zu einem späteren Zeitpunkt noch einmal" und ein Hinweis auf Prüfung von Störungen im RZ.

Von einer ebensolchen Störung ausgehend wollte ich es später erneut versuchen, wobei ich den eingegebenen Text nicht speichern konnte (https://www.datev-community.de/t5/Office-Management/Sonstige-Nachricht-Kein-Speichern-m%C3%B6glich/m-p/495339#M30217).

Bei einem anderen Mandanten konnte ich eben eine Sonstige Nachricht einreichen, bei ersterem aber immer noch nicht, so dass ich stutzig wurde. Nun musste ich feststellen, dass der überlange Eintrag in Name/Betriebsbez. offenbar für den Fehler verantwortlich war, nach Kürzung on diesem konnte ich die Nachricht senden.

Ich möchte anmerken, dass es sich um den automatisch übernommenen Namen der Gesellschaft handelte.

Dass ein überlanger Name nicht zulässig ist, von mir aus. Es frustriert mich aber ungemein, dass man hierauf nicht hingewiesen wird, sondern eine Fehlermeldung erhält, die auch noch auf das RZ verweist. Wie gesagt, dich bemerkte das Problem nur, weil es bei einem anderen Mandanten funktionierte. Meiner Ansicht nach war die Fehlermeldung nicht nur nicht hilfreich, sondern sogar irreführend.

Mit freundlichen Grüßen,

Florian Mayer

Beitrag verschoben und Kategorie entfernt durch @Sarah_Reitzmann 

[#2]

Hallo Herr Mayer,

wir können das von Ihnen geschilderte Programmverhalten auf unseren Systemen nicht nachvollziehen. 

Die Schnittstelle der Finanzverwaltung sieht bei der Erfassung der Bezeichnung max. 72 Zeichen vor. Wird diese Anzahl überschritten kommt beim Erzeugen der Vorschau oder dem Sendeversuch üblicherweise folgende Fehlermeldung: 

Die angelegte Sonstige Nachricht kann bei zu langer Bezeichnung (also mehr als 72 Zeichen) trotzdem gespeichert bzw. kann der Status geändert werden.

Wir werden das von Ihnen geschilderte Problem aber weiter beobachten und analysieren.

Viele Grüße,

Susanne Filchner

[#3]

Liebe Frau Filchner,

ja 72 Zeichen lange Strings (Zeichketten) sind schon recht viel. Aber halt immer noch nicht genug. Zumindest eine maximale Stringlänge von 255 Zeichen sollte Standard sein, ggf. auch ruhig von max. 64 kB . Hat nebenbei den Vorteil, dass Overflow-Fehler unwahrscheinlicher werden.

Speicherplatz ist seit sehr vielen Jahren nicht mehr rar. Ebenso Übertragungsgeschwindigkeiten über das Internet. Die Stringlängen sollten ihre Programmierer per Compilerdefinition vorgegeben haben. Es sollte also einfach sein, diese anzupassen.

Ich schreibe diese Antwort auch und vor allem, weil ich mehrfach schon Probleme mit unzureichend dimensionierten Eingabefelder hatte!

Das Problem ist künstlich erzeugt!

QJ

[#4]

Bei den Eingabefeldern muss ich DATEV loben. Nachdem ich viel mit Datev arbeite bin ich regelmäßig von Eingabemasken bei Behörden frustriert, z.B. wenn diese bei Datumseinträgen den Punkt haben wollen, denn was könnten 08072025 in einem Datumsfeld wohl für ein Datum sein?

Wegen den Problems mit der fehlerhaften Fehlermeldung habe ich eine Anrufbitte gesendet.

[#5]

Moin @quantenjoe,

ich gehe mal davon aus, dass Frau @Susanne_Filchner hier nichts machen kann, selbst wenn Sie wollte. Die Definition macht die Finanzverwaltung in der ELSTER-Schnittstelle, die zwingend zu nutzen ist.

Und jetzt wollen wir uns mal besser nicht vorstellen, wie die Arbeitsweise auf der "anderen Seite" bei der FV aussieht... 

Aber: Wenn wir mal annehmen, wir könnten Dateinamen gem. Ihrer Anregung mit 255-Zeichen nutzen, dann haben wir und die FV in den meisten Fällen direkt ein Problem. Denn die Dateisysteme NTFS können beginnend von der ersten Stelle bis zum letzten Punkt nur 255 Unicode-Zeichen aufnehmen und nutzen. 

Ich habe es schon erlebt, wie Kolleginnen und Kollegen Excel-Dateinamen als "Projekt-Beschreibung" nutzten und dann Excel gemeldet bekommen haben "Datei nicht gefunden". 

Im Öffnen-Dialog und auch im Datei-Explorer ist die Datei zu sehen... 

Ähnliche Probleme gab es auch schon bei Migrationen/Serveraustausch, wenn dann robocopy an einzelnen Dateien und Pfaden sich die Zähne ausgebissen hat... 

Ich zitiere mal auf die Schnelle:
Die maximale Länge für einen Dateinamen unter NTFS beträgt 255 Unicode-Zeichen. Für die Pfadlänge (einschließlich aller Verzeichnisnamen) sind bis zu 32.760 Unicode-Zeichen möglich, wobei jede Pfadkomponente (also jeder Ordner- oder Dateiname) selbst nicht länger als 255 Zeichen sein darf.

Wie gesagt, wir wollen uns besser nicht vorstellen, wie die FV arbeitet.

Aber selbst wenn wir ein DMS unterstellen (analog zum DATEV-DMS), dann haben wir die Nutzanwendung (Word, Excel, PDF), die *nie* direkt ein "Datei öffnen" aus dem DMS ermöglichen kann. Die gewünschte Datei wird immer aus dem DMS-Speicher in einen temporären Pfad des Clientbenutzer abgelegt. Und wenn wir dann wieder bei den 255-Zeichen sind, läuft der Benutzer direkt in die Öffnen-Falle...

Ich würde also mal unterstellen, dass es nichts mit Bandbreiten, Übertragungsgeschwindigkeiten oder Speicherplatz zu tun hat. Schlicht mit Begrenzungen einzelner Dateisysteme und die Kompatibilität untereinander gepaart mit dem Zusammenspiel von Anwendungen, DMS, SharePoints, oder was auch immer.

Beste Grüße
Christian Ockenfels

[#6]

---

@quantenjoe  schrieb:

Das Problem ist künstlich erzeugt!

QJ

---

Wie mein Vorschreiber schon schrieb:

Ja, aber nicht durch die DATEV, die von sich aus dort nichts ändern kann, weil es Vorgaben von der Finanzverwaltung sind (wie Frau Filchner aber auch bereits schrieb).

[#7]

Es lag anscheinend an unzulässigen Zeichen:

https://www.datev-community.de/t5/Office-Management/Vorsicht-bei-Bindestrichen-in-Untenehmensnamen/m-p/496425#M30312