Thema "Rewe: Paketname darf keinen . enthalten :-(((" in Betriebliches Rechnungswesen

Rewe: Paketname darf keinen . enthalten :-(((

Gelöschter Nutzer — Wed, 12 Aug 2020 08:01:13 GMT

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.

Rewe: Paketname darf keinen . enthalten :-(((

einmalnoch — Wed, 12 Aug 2020 08:07:43 GMT

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 😎

Rewe: Paketname darf keinen . enthalten :-(((

vogtsburger — Wed, 12 Aug 2020 08:21:28 GMT

... 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 😀

Rewe: Paketname darf keinen . enthalten :-(((

Gelöschter Nutzer — Wed, 12 Aug 2020 08:30:29 GMT

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

Rewe: Paketname darf keinen . enthalten :-(((

Gelöschter Nutzer — Wed, 12 Aug 2020 08:38:03 GMT

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

Rewe: Paketname darf keinen . enthalten :-(((

ww3 — Wed, 12 Aug 2020 09:01:45 GMT

Klappt hier aber einwandfrei:

Rewe: Paketname darf keinen . enthalten :-(((

vogtsburger — Wed, 12 Aug 2020 09:11:28 GMT

... 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 ...

Rewe: Paketname darf keinen . enthalten :-(((

bernd_wettstein — Wed, 12 Aug 2020 09:16:08 GMT

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.

Rewe: Paketname darf keinen . enthalten :-(((

Gelöschter Nutzer — Wed, 12 Aug 2020 09:19:42 GMT

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

Rewe: Paketname darf keinen . enthalten :-(((

einmalnoch — Wed, 12 Aug 2020 09:28:13 GMT

@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. 😎

Rewe: Paketname darf keinen . enthalten :-(((

Gelöschter Nutzer — Wed, 12 Aug 2020 09:39:17 GMT

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

Rewe: Paketname darf keinen . enthalten :-(((

einmalnoch — Wed, 12 Aug 2020 09:47:03 GMT

Es landet die Auswertung mit "Berater_Mandant_Jahr_Auswertung f." im Anhang. Live und in Farbe.

Rewe: Paketname darf keinen . enthalten :-(((

vogtsburger — Wed, 12 Aug 2020 10:00:52 GMT

@bernd_wettstein ,

... 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 🤔

Rewe: Paketname darf keinen . enthalten :-(((

Gelöschter Nutzer — Wed, 12 Aug 2020 10:01:20 GMT

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.

Rewe: Paketname darf keinen . enthalten :-(((

Gelöschter Nutzer — Wed, 12 Aug 2020 10:06:53 GMT

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

Rewe: Paketname darf keinen . enthalten :-(((

Gelöschter Nutzer — Wed, 12 Aug 2020 11:44:50 GMT

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. 😎

Rewe: Paketname darf keinen . enthalten :-(((

jjunker — Wed, 12 Aug 2020 13:05:52 GMT

Umlaute tippe ich bei egal welchem Datenbanksystem nie und wenn man sich einfach an die DOS Namensregeln hällt hat man keine Probleme.

Rewe: Paketname darf keinen . enthalten :-(((

Gelöschter Nutzer — Wed, 12 Aug 2020 13:15:04 GMT

@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... 🙂

Rewe: Paketname darf keinen . enthalten :-(((

jjunker — Wed, 12 Aug 2020 13:35:46 GMT

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.

Rewe: Paketname darf keinen . enthalten :-(((

Gelöschter Nutzer — Wed, 12 Aug 2020 14:24:22 GMT

@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 😉

Rewe: Paketname darf keinen . enthalten :-(((

vogtsburger — Wed, 12 Aug 2020 17:12:29 GMT

@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😀.

Rewe: Paketname darf keinen . enthalten :-(((

MBehrens — Wed, 12 Aug 2020 21:16:11 GMT

@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.

Rewe: Paketname darf keinen . enthalten :-(((

bernd_wettstein — Thu, 13 Aug 2020 17:36:34 GMT

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.

Rewe: Paketname darf keinen . enthalten :-(((

Nida_Niazioglou — Tue, 18 Aug 2020 08:41:16 GMT

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