Belegtransfer Protokoll "erwartete Datei aus Dokumenteninformation jedoch nicht gesendet! "

[#1]

Ich versuche eine Belege-XML mit ca. 1.600 Ausgangsrechnungen per Belegtransfer 5.24 hochzuladen.

Ist das Paket zu groß?

Lt. Protokoll wurde der Großteil hochgeladen die letzten ca. 30 Rechnungen stehen im Protokoll mit dem Fehler

"erwartete Datei aus Dokumenteninformation jedoch nicht gesendet! "

Im Belegtransfer ist das Paket archiviert.

Woran kann es nur liegen? Ich hab´s noch einmal versucht mit dem selben Ergebnis. Dauert der Transfer zu lange und DUO meldet sich ab?

Die nicht gesendeten PDF sind im Zip Archiv vorhanden, das habe ich geprüft.

Sind jetzt nur die letzten Belege nicht hochgeladen, oder werden alle Belege abgelehnt, wenn solch ein Fehler auftritt?

[#2]

---

@joergpauli schrieb:

Ist das Paket zu groß?

---

Wie groß ist die Datei in MB denn? 

Ich nehme an, dass Du jetzt den Extremfall beschreibst, weil wir schon über eine 4MB Datei meckern, wie lange die vom lokalen PC bis ins DUO braucht: Belegtransfer V.5

Wenn Du möchtest, kann ich Dir v3.7x zukommen lassen, womit es deutlich schneller funktionieren wird. 

[#3 · Accepted solution]

Die Größe einer einzelnen Datei darf 20MB nicht übersteigen.

Für gezippte Archive gilt:

• Maximale Dateigröße je Einzeldatei 20 MB

• Maximale Anzahl Dateien im ZIP-Archiv 5000 (inkl. XML-Dateien)

• Maximale Größe der ZIP-Datei 476 MB

Nachtrag:

... für mich sieht es eher danach aus, dass in der .xml-Datei auf Dokumente (PDFs) verwiesen wird, die in der zip-Datei zwar vorhanden, aber evtl. ungültig sind. Vielleicht in einem anderen Format oder nicht identifizierbar oder Ähnliches.

Man könnte die Zip-Datei manuell extrahieren und die entsprechenden Belege separat per Belegtransfer hochladen

Auf "Unternehmen Online" kann man ja checken, ob schon etwas angekommen ist und wenn ja, wieviele Belege

[#4]

@metalposaunist 

Das ist sehr nett von Dir, aber da wir auf der ASP unterwegs sind und ich auf gar keinen Fall irgendwelche SW installieren darf, wird mir das nichts nützen.

Die xml Datei hat immerhin 860 MB

Die pdf Dateien sind im Schnitt 550 KB groß

Vielleicht liegt's wirklich an korrupten Daten. Bei diesem Mandanten habe ich den Sermon gerade erst eingerichtet.

Der Export aus der Shopsoftware war schon abenteuerlich.

Danke Euch

Da kam Edit auf mich zu und sagt: der Vogtsburger hat doch geschrieben max 476mb, deine -XML ist doppelt so groß. 

[#5]

---

@joergpauli schrieb:

wird mir das nichts nützen.

---

Zur Not kann man den alten Belegtransfer lokal installieren. Dazu braucht man kein asp und keine DATEV Umgebung. 

---

@joergpauli schrieb:

deine -XML ist doppelt so groß.

---

Jupp. Dann kannst Du den Export nur splitten und dadurch mehrfache ZIPs erzeugen. Auch dann wird das 0 Spaß machen, wenn 42MB schon eine gefühlte Ewigkeit dauern 🙄. Kurzum: Wenn Du die > 800MB dann mal im DUO hast, gib gerne Bescheid, wenn Du noch Nerven am Ende übrig hast 😶.

[#6]

---

@joergpauli  schrieb:

[...]

Die xml Datei hat immerhin 860 MB

Die pdf Dateien sind im Schnitt 550 KB groß

[...]

... habe da so meine Zweifel, ob das Splitten in Eigenregie funktioniert.

Es wäre zwar kein Problem, die übergroßen ZIP-Datei zu extrahieren und kleinere ZIP-Archive zusammenzustellen, aber wie erzeugt man die zugehörigen neuen XML-Dateien ?

... vielleicht reicht ja aber auch zur Not das manuelle Hochladen aller Einzeldateien

... ist allerdings eine Sisyphusarbeit 

Apropos, wir haben einen Mandanten, der neuerdings auch Belege mit dieser Dateigröße von über 500 KB 'produziert'

.. er hat sich für sein neues Rechnungsformular sein Portrait als 'Wasserzeichen' gewünscht🙄

... mal sehen, wie er reagiert, wenn man ihm sagt, dass sich dieses neue 'Feature' an mehreren Stellen rächt 😉

[#7]

---

@vogtsburger schrieb:

... habe da so meine Zweifel, ob das Splitten in Eigenregie funktioniert.

---

Klar. Beim Export der Daten im Quellsystem nicht (übertrieben) 01.01.2022 bis 31.12.2022 angeben, sondern 12 Exporte je Monat machen; ergibt 12x kleinere ZIP Dateien.  

---

@vogtsburger schrieb:

.. er hat sich für sein neues Rechnungsformular sein Portrait als 'Wasserzeichen' gewünscht🙄

---

Weil klar geregelt ist, was in eine deutsche Rechnung gehört; nur nicht wie: PDF, ZUFeRD, XRechnung Version ..  

[#8]

---

@metalposaunist  schrieb:

---

@vogtsburger schrieb:

... habe da so meine Zweifel, ob das Splitten in Eigenregie funktioniert.

---

Klar. Beim Export der Daten im Quellsystem nicht (übertrieben) 01.01.2022 bis 31.12.2022 angeben, sondern 12 Exporte je Monat machen; ergibt 12x kleinere ZIP Dateien.  

... ich bin davon ausgegangen, dass das 'Konvolut' keine Jahresbuchhaltung ist, sondern das Belege-Volumen, das in einem Monat 'produziert wurde.

... aber es wurde nicht davon gesprochen, ob auch ein Buchungsstapel im Datev-Format mitgeliefert wird

... falls ja, könnte man mit "ISWL_Beleg2Buchung" 'die Kuh vom Eis kriegen'

Apropos, bei unserem o.g. Mandanten hatten die alten Belege eine Dateigröße von ca 20 KB, die neuen Belege eine Größe von ca 500 KB 🙄

[#9]

Danke Euch, für die Unterstützung.

Es war ein Versuch, aber so werde ich nicht weiterkommen.

Die einzelnen PDF sind zu groß, das Gesamtpaket auch.

Das ist das Ergebnis einer Woche aus einem Webshop.

Natürlich soll dass alles mit einem Buchungsstapel verarbeitet werden.

Das funktioniert ja soweit auch, bis auf fehlerhafte Einstellung bei Konten, Steuersatz Moss usw.

Da muss also schon in der Shopsoftware viel eingerichtet werden.

Ich habe gestern Abend noch einmal den Upload im Belegtransfer gestartet.

Genauso wie vorher werden die letzen 30 Positionen mit Fehler markiert und das ganze Paket in den Orkus verlegt.

Es werden aber auch die Belege die angeblich ja geklappt haben nicht im DUO angezeigt. 

Das Splitten wird sicherlich an der falschen dokument.xml scheitern.

ISWL_Beleg2Buchung könnte klappen, aber da höre ich schon wieder das Gejammer über die Kosten.

Ich mache es smart, delegieren und abwarten. 

[#10]

... wenn die doch ziemlich 'überschaubare' monatliche Gebühr für "ISWL_Beleg2Buchung" zum Problem 'hochsterilisiert' wird, will ich lieber nicht weiterfragen 😎

... da könnten nämlich noch andere Leichen im 'Nebel des Grauens' liegen 😅

[#11]

---

@vogtsburger schrieb:

... ich bin davon ausgegangen, dass das 'Konvolut' keine Jahresbuchhaltung ist, sondern das Belege-Volumen, das in einem Monat 'produziert wurde.

---

OK. Dann halt statt Export 01.01.2023 - 31.01.2023 eben mehrere Exporte: 01.01.2023 - 10.01.023 / 11.01.2023 - 20.01.2023 / 21.01.2023 - 31.01.2023. Dann hat man auch kleinere ZIPs. 

---

@vogtsburger schrieb:

... falls ja, könnte man mit "ISWL_Beleg2Buchung" 'die Kuh vom Eis kriegen'

---

Warum? In der ZIP steht alles schon fertig beschrieben drin. Da braucht man kein Beleg2Buchung, was ebenfalls wieder manuelle Mehrarbeit ist und ziemlich umständlich dazu 😂. Spaß macht das nicht wirklich. Das ist ein Programm aus 199X. 

---

@joergpauli schrieb:

Das Splitten wird sicherlich an der falschen dokument.xml scheitern.

---

Ich wüsste nicht warum. Mit 3 Exporten wird jeweils einen neue XML erzeugt.  

[#12]

nee. Lieber nicht 🙂

delegieren ist natürlich nicht, in kleineren Paketen läuft das Ganze schnuckelig sauber durch und macht keine Zicken.

Aber es ist natürlich sehr speziell und bereitet mir namenlose Freude, wenn ich aus der Faktura einzelne Tage abrufen muss, verarbeiten und Belege hochladen.

Selbst die Datenmenge von 2 Tagen wird ihm zu viel.

[#13]

@joergpauli ,

... würde mich tatsächlich interessieren, welches 'professionelle' Shopsystem solche Volumina produziert ...

... damit ich einen großen Bogen um dieses Shopsystem machen kann 😄

nach meiner Erfahrung gilt nähmlich das Motto:

je professioneller das Shopsystem, desto kleiner die Datenmengen und desto schneller die Prozesse

... wenn man ständig aufpassen muss, dass die 'Grenzen des (Beleg-)Wachstums' nicht überschritten werden, bleibt einem nicht mehr viel Zeit für etwas Anderes 😎

... evtl. käme ja auch noch eine andere bzw. direktere Schnittstelle (API u.a.) infrage

@metalposaunist ,

.. dass man sogar mehrere Exporte pro Monat ausführt bzw. ausführen muss, hatte ich jetzt nicht auf dem Schirm

Aber wenn das praktikabel ist .... ok ...., dann muss man eben die Zeit zwischen jeweils zwei Exporten und nachfolgenden Belegtransfers noch sinnvoll nutzen 😄

... oder den Belegtransfer-Ordner automatisch überwachen lassen 

Apropos,

wenn mich nicht alles täuscht, verpackt "ISWL_Beleg2Buchung" übergroße Konvolute in mundgerechte Portionen, die man dann in einem Aufwasch verarbeiten und transferieren kann

... daher ...

"wer wird denn gleich in die Luft gehen ? greife lieber zu HB ... ähm ... zu ISWL.."

(man sieht, dass Fernsehwerbung eben doch noch langfristig nachwirkt, vor allem bei Software aus dem vorherigen Jahrtausend) 😅

@joergpauli , man kann das zu bezahlende Speichervolumen ja schon mal vorsorglich hochrechnen 😉

[#14]

ich weiß nicht, ob ich mir Ärger einhandele wenn ich diese Software namentlich nenne und meien Meinung dazu kundtue. Naja, freie Meinungsäusserung, oder? Ich liebe Shopware

Ich denke, das Problem ist eher noch auf der Einrichtungsseite zu suchen. Der DATEV Export wurde/Musste als Plugin zusätzlich von Drittanbieter dazu geordert werden. 

Aber die Datenmenge mit 10 - 15K an einzelnen Verkäufen gibt es nun mal. Sicherlich könnte man die PDF noch kleiner machen, Das Plugin schmiert mir aber schon ab, wenn ich eine komplette Woche exportieren möchte.

Aber da ist man sich ja einig, die andere SW ist schuld. Es macht auch einen Unterschied, ob auf der ASP online gehe und den Export anwerfe, oder lokal.

Es ist nicht ungewöhnlich, dass Mandanten mit tagesaktuellen Zahlen versorgt werden.

Zu Glück habe ich Systemeinrichtung und Pflege schon vor langer Zeit aus meinem Portfolio gelöscht.

Das war als die DATEV die Zusammenarbeit mit NOVELL aufgekündigt hat 😀

Damals hatte ich gerade den Schein "DATEV Systemadministrator für Novellnetzwerke" in der Tasche. 

Also ca. 25 Jahre her.

Heute kann ich mich hinstellen und sagen: geht nicht, alles shize, geht immer kaputt, mach wieder heil"

[#15]

jetzt stellt sich gerade die Frage, ob es denn erlaubt ist, die PDF aus dem Shopsystem zu exportieren, dann mit einem Tool zu schrumpfen und ins DUO hochzuladen.

In den Gobd habe ich auf die schnelle jetzt nichts passendes finden können. Aber eigentlich möchte ich das nicht.

Es muss doch möglich sein, der !"§$ Software beizubringen, datenmäßig kleine PDF zu erstellen.

[#16]

@joergpauli ,

reiner Text 'verbraucht' nur sehr wenig Bytes, aber manchen Rechnungsformular-'Designern' ist ein tolles, hochauflösendes Bild oder Logo oder ein formatfüllendes Wasserzeichen oder ein mehrfarbiges Briefpapier offenbar seeeehr wichtig, ohne Rücksicht auf das Speichervolumen.

... das rächt sich an mehreren Stellen

Das nachträgliches Verkleinern der Digitalen Originalbelege hätte Thorsten Dirks sicher auch zu den **bleep***-Prozessen gezählt 😉

[#17]

jetzt musste ich erst einmal überlegen, wen Du meinst.😅

ja, das wäre auf jeden Fall ein ***Prozess, aber digital 🤗

Mir geht es aber auch um die Frage, ob es GoBd konform wäre.

Die Dokumente sind dann ja nicht mehr identisch