Man freut sich immer wieder über die doofe Künstliche Intelligenz ....
Wenn in ReWe ein "Auswertungspaket für Mandanten" nicht so heißt, sondern ""Auswertungspaket f. Mandanten" macht die Datev beim PDF Export daraus nicht "Auswertungspaket f Mandanten.pdf" , sondern "Auswertungspaket f.", was zu einem nicht als PDF erkennbarem Dateianhang führt....
Tipp für die menschliche Intelligenz: Entweder muss direkt bei der Benennung eines Paketes der "." nicht zugelassen werden oder bei der Konvertierung ins PDF Format der "." ersetzt werden.
Na ja, es dauert eben, bis sich die Erkenntnis durchsetzt das sich die Regeln für Dateinamen seit DOS geändert haben. DATEV lässt aber Umlaute in Dateinamen zu, eine Ablage in DMS classic wird damit wirksam verhindert.
Mit ist der englische Begriff lieber: AI = Absent intelligence 😎
... apropos Dateinamen:
gibt es in der Datev-Welt noch weitere Einschränkungen bezüglich der Dateinamen, über die man stolpern könnte ?
... ich denke hier an so nette (bei uns real existierende) Dateinamen wie z.B.
ba27e388-194a-4f56-82e9-f441a44c07b3__ed67ad27-de71-4e9b-9a2f-0fb8833dae5e.PDF
zum Glück haben diese Dateinamen weder Punkte, noch Umlaute, noch andere Sonderzeichen oder Hieroglyphen. Es ist anscheinend 'bloß' die Kombination zweier pseudozufälliger GUIDs 😀
Also bitte die Unzulänglichkeiten von DATEV nicht mit der von Windows vermischen.
Windows kann sehr wohl den "." in einem Dateinamen verwenden. Wenn DATEV das aber nicht kann, liegt hier das Problem.
Und das wäre den der Fehler Nr. 7236 in der nicht enden wollenden Liste. 😋
Gruß Achilleus
GUID sind mathematisch gesehen mit nahezu 100% Wahrscheinlichkeit absolut einmalige Codenummern.
Zitat aus der Online-Hilfe zu VBNet:
Stellt eine GUID dar (Globally Unique Identifier, globaler eindeutiger Bezeichner).
Zu vermerken ist, dass DATEV hier sogar zwei GUID-Nummern miteinander verbindet, also ein Hosenträger- und Gürtelverwender-Typ. 😂
Allerdings macht es hier durchaus Sinn, da aufgrund der Vielzahl der Belege es eben doch einmal zu Dubletten kommen könnte.
Gruß Achilleus
Klappt hier aber einwandfrei:
... habe nur die Befürchtung, dass z.B. die maximale Länge des gesamten Pfads (z.B. bei einem Beleg-Link) irgendwo an die (Feld-)Grenzen stößt.
... muss mal kontrollieren, wieviele Zeichen der Beleglink im Datev-Format haben darf ...
Hallo zusammen, hallo Herr @vogtsburger ,
>... ich denke hier an so nette (bei uns real existierende) Dateinamen wie z.B.
> ba27e388-194a-4f56-82e9-f441a44c07b3__ed67ad27-de71-4e9b-9a2f-0fb8833dae5e.PDF
Ja, es ist denkbar, dass es hier zu Problemen kommen kann und zwar in dem Fall was die Gesamtpfadlänge angeht. Bis heute wird hier deutlich weniger als maximal 250 Zeichen empfohlen obwohl NTFS längst mehr kann.
1.) Wg. Windows (sehr indirekt, eigentlich wg. Explorer bzw. Programmen die mit der ehemaligen Einschränkung seltsam hantieren. NTFS selbst kann per Definition m.E. ca. 40.000 Zeichen.)
2.) In AP Comfort / Problemen beim Umbenennen innerhalb des Aktenbaums wenn darin eine Anlage / ein Arbeitspapier gezogen wurde, welches sehr lange Dateinamen hat.
Grüße, Bernd Wettstein.
Meines Wissens kann der Explorer zwar Dateien mit deutlich mehr als 250 Zeichen incl. Pfadnamen anzeigen, aber diese Dateien können nicht geöffnet oder umbenannt werden. Erst wenn man die Verzeichnisse kürzt, also durch umbenennen oder man die Datei in einen kürzeren Pfad kopiert (verschieben funktioniert IMO nicht), ist die Datei wieder zur Bearbeitung freigeben.
Gruß Achilleus
@Gelöschter Nutzer schrieb:Man freut sich immer wieder über die doofe Künstliche Intelligenz ....
Wenn in ReWe ein "Auswertungspaket für Mandanten" nicht so heißt, sondern ""Auswertungspaket f. Mandanten" macht die Datev beim PDF Export daraus nicht "Auswertungspaket f Mandanten.pdf" , sondern "Auswertungspaket f.", was zu einem nicht als PDF erkennbarem Dateianhang führt....
Tipp für die menschliche Intelligenz: Entweder muss direkt bei der Benennung eines Paketes der "." nicht zugelassen werden oder bei der Konvertierung ins PDF Format der "." ersetzt werden.
@Gelöschter Nutzer
Es wäre schön, wenn Sie geschrieben hätten wo das Verhalten auftritt. Im ersten Moment wird das Dateisystem assoziiert, da tritt es so nicht auf. Wird aber das Ausgabeziel "E-Mail Vewrsand" gewählt ist das Verhalten nachstellbar. Hier scheint der Schnittstellnparser einen kleinen Schlag an der Schüssel zu haben, DATEV macht ja keine Fehler. 😎
Hallo @einmalnoch,
ich müsste mich schon sehr täuschen, aber selbst die Uralt-Schnittstelle MAPI beherrscht Sonderzeichen wie "." im Dateinamen.
Ich habe zwar hier kein VB 6.0-Programm mehr, habe aber in der Vergangenheit ja auch die MAPI genutzt und da gab es IMO nie Probleme.
Gruß Achilleus
Es landet die Auswertung mit "Berater_Mandant_Jahr_Auswertung f." im Anhang. Live und in Farbe.
... mich interessieren hauptsächlich die Längenbegrenzungen in der Praxis des digitalen Belegbuchens.
Das Feld "Beleglink" im "Datev- bzw. ASCII-Format" ist offenbar ein Textfeld mit einer Länge von 210 Zeichen, wobei der Pfad wohl nicht erfasst wird, sondern nur ein Kürzel für die Anwendung und der eigentliche Dateiname, z.B. unter Verwendung der GUID.
Vermutlich gibt es aber 'ungültige' Zeichen, die REWE nicht interpretieren kann. Hexadezimal-Zeichenketten sollten aber keine Probleme bereiten.
Nachtrag:
Allerdings irritiert mich der Hinweis in der Beschreibung des Feldes "Beleglink"
Der Beleglink hat folgenden Aufbau:
4-stelliges Kürzel für Dokumentenmanagementsystem (siehe unten)
Leerzeichen
Anführungszeichen
Beleglink (GUID, Dateiname des Belegs), max. 36 Zeichen
Schlusszeichen
Beispiel für einen Beleglink aus Belege online:
BEDI “CB6A8F8F-099A-B3A9-2BAA-0CB64E299BA”
Das Kürzel bezeichnet das Quellsystem(Dokumentenmanagement), indem die digitalen Belege abgelegt sind. DATEV verwendet für seine Dokumentenmanagement-Systeme folgende Kürzel:
Belegverwaltung online → BEDI
DATEV DMS → DDMS
Dokumentenablage → DDMS (vormals DORG)
Wenn der Beleglink (die GUID bzw. der Dateiname) nur 36 Zeichen haben darf, würde ich mit meinen o.g. Kandidaten gegen die Wand laufen 🤔
Hallo @einmalnoch,
das glaube ich gerne. Die Frage ist aber, liegt es an der MAPI oder an der Wertübergabe von DATEV. Und vorsichtig gesagt liegt vermutlich hier ein Fehler seitens DATEV vor. Ich kann es aber nicht mit Bestimmtheit sagen, da ich das zumindest im Augenblick nicht verifizieren kann.
Hallo Hr. Vogtsburger,
vielleicht sind diese Dateien mit dem Namen
ba27e388-194a-4f56-82e9-f441a44c07b3__ed67ad27-de71-4e9b-9a2f-0fb8833dae5e.PDF
gar kein einzelnes PDF, sondern 2 Dateien die nur geheftet wurden. Dann würde nämlich der Aufbau Sinn machen:
ba27e388-194a-4f56-82e9-f441a44c07b3__ed67ad27-de71-4e9b-9a2f-0fb8833dae5e.PDF
Dokument1_Dokument2.pdf
Denn Heften ist ja nicht das Zusammenführen von PDF-Dateien, sondern lediglich die Verkettung.
Gruß Achilleus
liegt wahrscheinlich daran, dass es mir um den Mailversand ging, siehe @einmalnoch (Danke für den Hinweis)
@einmalnoch schrieb:Es wäre schön, wenn Sie geschrieben hätten wo das Verhalten auftritt. Im ersten Moment wird das Dateisystem assoziiert, da tritt es so nicht auf. Wird aber das Ausgabeziel "E-Mail Vewrsand" gewählt ist das Verhalten nachstellbar. Hier scheint der Schnittstellnparser einen kleinen Schlag an der Schüssel zu haben, DATEV macht ja keine Fehler. 😎
Umlaute tippe ich bei egal welchem Datenbanksystem nie und wenn man sich einfach an die DOS Namensregeln hällt hat man keine Probleme.
@jjunker schrieb:Umlaute tippe ich bei egal welchem Datenbanksystem nie und wenn man sich einfach an die DOS Namensregeln hällt hat man keine Probleme.
Wenn ich einem Mandanten Dateien schicke, sollten Umlaute möglich sein, wir leben ja schließlich nicht mehr im
vorherigen Jahrhundert 🙂
Ein Mailversand einer Datei mit "f." aus der Dokumentenablage klappt übrigens:
Also liebe DatevkollegInnen ... redet mal miteinander, um zu erfahren, wie die anderen das so toll hinbekommen haben... 🙂
da stellt sich mir die naechste Frage. Wer kuerzt fuer mit f. ab? da spart man selbst in der DOS Schreibweise nur zwei Zeichen. 😋 Aber wenn es an anderer Stelle geht, sollte es DATEV weit funktionieren, da bin ich bei Ihnen.
@jjunker schrieb:Wer kuerzt fuer mit f. ab? da spart man selbst in der DOS Schreibweise nur zwei Zeichen. 😋
da haben Sie recht, war auch nur als Beispiel gedacht 😉
@Gelöschter Nutzer schrieb:...
vielleicht sind diese Dateien mit dem Namen
ba27e388-194a-4f56-82e9-f441a44c07b3__ed67ad27-de71-4e9b-9a2f-0fb8833dae5e.PDF
gar kein einzelnes PDF, sondern 2 Dateien die nur geheftet wurden. Dann würde nämlich der Aufbau Sinn machen:
...
@Gelöschter Nutzer ,
... diese Dateien (mit zwei GUIDs im Dateinamen) erhalten wir so von einem Mandanten, zusammen mit entsprechenden XML-Dateien und Excel-Tabellen mit jeder Menge an Informationen (inkl. der Buchungsdaten, der GUIDs und der Beleglinks).
Die Dateien stammen aus einem SAP-System.
Die PDFs sind in der Regel 1-seitige Dokumente.
Da diese Daten aber nicht direkt in einem 'fertigen' Datev-Format vorliegen, müsste man wohl erst noch viel Aufwand treiben, um daraus einen REWE-Buchungsstapel zu 'schnitzen'.
Dafür fehlt mir aber die Motivation und die Zeit. Das Belege-Volumen dieses Mandanten ist auch nicht so groß, dass man dazu gezwungen wäre.
Ursprünglich hatte ich die Hoffnung, dass man fertige Buchungsstapel erhält und in REWE importieren kann, inkl. der Beleglinks, aber es gibt hier noch keine Datev-Schnittstelle.
Ich werde dann eben die digitalen Original-Belege (die PDFs) nach Unternehmen Online hochladen. Die OCR müsste eigentlich 'leichtes Spiel' damit haben, hoffentlich😀.
@bernd_wettstein schrieb:Hallo zusammen, hallo Herr @vogtsburger ,
>... ich denke hier an so nette (bei uns real existierende) Dateinamen wie z.B.
> ba27e388-194a-4f56-82e9-f441a44c07b3__ed67ad27-de71-4e9b-9a2f-0fb8833dae5e.PDF
Ja, es ist denkbar, dass es hier zu Problemen kommen kann und zwar in dem Fall was die Gesamtpfadlänge angeht. Bis heute wird hier deutlich weniger als maximal 250 Zeichen empfohlen obwohl NTFS längst mehr kann.
1.) Wg. Windows (sehr indirekt, eigentlich wg. Explorer bzw. Programmen die mit der ehemaligen Einschränkung seltsam hantieren. NTFS selbst kann per Definition m.E. ca. 40.000 Zeichen.)
So einfach ist es leider nicht. Da spielen viel mehr Komponenten eine Rolle. Dies sind unter anderem Client Betriebssystem, Server Betriebssystem, Dateisystem und Windows API. Wirklich fallen tut dies erst ab Windows 2016/10 Version 1607 auf dann etwa 32700 Zeichen in der Gesamtlänge, wenn die passende Windows API verwendet wird.
Hallo zusammen,
@MBehrens : ich gebe zu, dass ich (womöglich unzulässig) vereinfacht habe, schon alleine aus der Erinnerung heraus. Man kann ja mittlerweile sogar nachlesen, dass man bei den werkseitigen Beschränkungen in älteren Versionen von Windows (mehr oder weniger auf eigene Gefahr) per Registry nachhelfen kann, das in Windows 2016/2019 umgesetzte auch dort schon im Bereich Windows I/O, NTFS, API und Explorer nutzen zu können.
Nur hilft das in der Praxis nicht viel, wenn die darauf laufenden Anwendungen weiterhin Strings mit 255 Zeichen oder weniger für Pfad+Dateiname verwenden oder andersartig einschränken (Gruß an Strato i.S. HIDrive-Client, WinRAR - https://t1p.de/0isg, DATEV in diversen Anwendungen mit Filebezug, usw. .... ) 😉
AP Comfort bekommt m.E. schon ganz unabhängig vom Pfad alleine schon beim Dateinamen mit deutlich weniger als 255 Zeichen "Stress" beim Umbenennen von Dateien, was dann wieder über Direktzugriffe über den Explorer (Hüstel) behoben werden kann.... Seufz.
Viel bemerkenswerter ist ja an dem Beitrag von @Gelöschter Nutzer , dass DATEV offenbar selbst Dateinamen vorschlägt, die dann betrebssystem- oder anwendungsseitig Probleme wg. der Notation machen.
Viele Grüße, Bernd Wettstein.
P.S.: hach, was regen wir uns auf. Der Beitragseditor der Community akzeptiert ja bis heute nicht mal das HTML, welches er selbst produziert (gerade eben wieder passiert 😉 ). Seien wir doch einfach froh seit OS/2, Win 9x und NT4 keine 8.3-Dateinamen mehr verwenden zu müssen. 😄 Und Schuld an alle dem ist ja dann ohnehin DEC und die PDP-Systeme (R.I.P.), bzw. Digital Research & CP/M (ebenfalls R.I.P.) die ebenfalls 8.3-ähnliche Konventionen hatten die dann später einfach so auf MS-DOS, Win9X und NT übertragen und dann im Nachgang erst mit VFAT und ähnlichen Erweiterungen dann auch hin zu HPFS und NTFS längere Dateinamen im fließenden Übergang parallel zu 8.3-Dateinamen unterstützt haben. Ist ja erst 20 Jahre her das Ganze.... 😄
P.P.S.: ISO9600-Dateisysteme für gebrannte CDs können nur Dateinamen mit 31 Zeichen... 😉 UDF immerhin schon 1.023 Zeichen für den Pfad.
Hallo,
hierzu finden Sie im folgendem Dokument eine temporäre Abhilfe und nähere Informationen:
Auswertungspakete als E-Mail exportieren – PDF-Datei wird nicht erstellt
Der Fehler wird ab den DATEV-Rechnungswesen-Programmen 9.0 (Vollversion, DATEV-Programme 14.0, Bereitstellung voraussichtlich 04.09.2020) behoben.
Neueste Informationen zur Auslieferung von DATEV-Programmen: www.datev.de/softwareauslieferung