Inaktiv PDF Dateigröße bei Rechnungen? Kleiner bekommen?

[ag-websolutions.de]

Denke dran dass du die dokumente in der Regel 10 jahre aufbewahren muss ... lesbar .... pdf -format ist nicht für langzeitarchivierung geeignet ... dafür wurde extra pdf/a entwickelt

 

[chx_de]

Hi,

ich dachte, wenn ich das "normale" PDF der Standardvorlage in den Scan Ordner von ecoDMS speichere, dass es dort dann von dem System in ein PDF/A umgewandelt wird. Richtig?

Dann könnte ich das 8kb PDF an den Kunden per Mail versenden, das gleichzeitig zusammen mit der Mail in unserem Google Vault archivieren und dann noch als PDF/A im ecoDMS ablegen.
Wenn nicht, dann müsste ich mit Zusatz Software das aus JTL erzeugte PDF/A verkleinern. Das habe ich aber noch nicht hinbekommen. Ich glaube, da muss ich noch ein paar Parameter übergeben.

 

[ag-websolutions.de]

Sofern du ecoDMS nutzt ist das korrekt.

 

[wawi-dl]

Jepp, wird umgewandelt ...

Nochmal, schau dir DATEV UO auf jeden Fall genau an! Jetzt nur mal ein Beispiel, ohne die Preise nachzuschauen, um die Rechnung zu verstehen:
1. Jahr ... 20 GB ... 50 EUR/Monat
2. Jahr ... 40 GB ... 75 EUR/Monat
3. Jahr ... 60 GB ... 100 EUR/Monat
4. Jahr ... 80 GB ... 125 EUR/Monat
5. Jahr ... 100 GB ... 150 EUR/Monat
....
10. Jahr ... 200 GB ... 275 EUR/Monat

Heißt, du würdest ab dem 10. Jahr dann monatlich schon 275 EUR bezahlen, die Kosten steigen und steigen also jährlich, das ist krank.
Da amortisiert sich ein eigener Server + DMS-System schon sehr schnell.

 

[chx_de]

Hi,

habe mir ecoDMS auf unserem Server installiert. Aber die Wawi hängt sich ständig auf. Ich denke, dass ich die Leistung vom Server nach oben setzen muss, oder?

Im Moment habe ich 2 Core und 4 GB eingestellt. Für die SQL Datenbank werden 950 reserviert und die Java Runtime für den ecoDMS Server bekommt 1 GB zugesprochen. Ich kann mir vorstellen, dass dann mit 2-3 Remote Desktop Benutzer, der Server ausgelastet ist?

Grundsätzlich ist aber ein Betrieb parallel zur JTL Wawi auf der selben Hardware (Cloud Server HVM ) möglich?
Gibt es Erfahrungen bezüglich Prozessor und Speicher?

 

[Petuchov]

Als normale Dateigröße für ein Rechnungs-PDF ersehe ich einen Bereich von 120- 150 KB
Wenn man diese mit einem Tool dann vor dem Hochladen einmal via Stapelverarbeitung optimiert sollten da nicht mehr als 40 KB rauzskommen
Ich habe bisher keine Möglichkeit gefunden , die PDFs über List und Label ordentlich zu definieren

links optimierte Date, rechts Original
Logos und Erstelleranschrift aus Datenschutzgründen unkenntlich gemacht

Mit dem PDF Format lassen sich mehrere Hundert Seiten inclusive Farbbildern auf wenigen MB erstellen.

Ein Katalog Z.B hat (optimal gespeichert) mit 70 Seiten keine / 5 MB, und zwar mit Photos

PDF ist eine Wissenschaft für sich, weil es aus der Druckindustrie kommt, und für alle möglichen Verwendungszwecke konfigurierbar ist
In einen modernem Betrieb sollte deshalb ein Acrobat Professional verfügbar sein.
Die Zeiten, wo das mal mehr alls 1000 € gekostet hat, sind erfreulicherweise vorbei

Wenn man seine Rechnungen in einen überwachten Ordner reindruckt kann man mit dem Destiller / Aktionsassistent seine Daten optimieren

Man benötigt auch nicht die neueste Version, eine Version 6 gibt es schon in der Box ab 50 €

INFOS zu den Anforderungen hier:

http://www.pdf-tools.com/pdf20/de/news/publications/pflicht-und-kuer-in-der-langzeitarchivierung/

Auszug:
Das Archivformat hat eine unterschätzte, jedoch wesentliche Bedeutung. So gehören der Nachweis der Integrität der Dokumente sowie die Nachvollziehbarkeit von Änderungen zu den Leistungsmerkmalen des Dokumentenformats. Archivare empfehlen PDF/A als Dateiformat, das speziell für die langfristige Aufbewahrung von digitalen Dokumenten entwickelt wurde. Um die Qualität der erzeugten PDF/A-Dateien sicherzustellen, wird am besten ein zentraler Dienst eingesetzt. Mittels „Torwächter“ (Validator-Software) wird sichergestellt, dass im Archivsystem nur langfristig lesbare Dokumente abgelegt werden können. Kosten und Risiken bei der Archivierung bewerten Vor der Umsetzung von Projekten zur Archivierung digitaler Dokumente sind die rechtlichen, organisatorischen, technischen und wirtschaftlichen Aspekte hinreichend zu untersuchen.



10 000 Rechnungen ergeben dann eben mal gerade 310 MB statt 1.2 GB, wie mit meinen Beispieldateien

 

[wawi-dl]

Ich denke es wurde doch schon alles gesagt, kleiner als klein geht einfach nicht!
List&Label kann momentan nicht mehr über die JTL ausgeben, da ist man aber dran.
Wir würden uns ohne PDF/A 30-60% Platz sparen, in PDF/A ist bei 100-150KB einfach schluss.

IHR müsst entscheiden, ob PDF oder PDF/A, zwingende Pflicht ist es nicht, wir haben uns aber dennoch dafür entschieden.

Gründe:
Speicherplatz kostet heute kaum noch groß Geld, ecoDMS läuft aktuell nach Stresstest mit 50.000 Rechnungen (260kb/PDF) mit 6-7GB noch immer stabil und performant.

 

[SebastianB]

Hi,

also bezüglich PDF-A und nicht PDF-A und was List&Label kann steht ja alles in diesem Thread:

Mit PDF-A *müssen* die Schriftarten in die PDF eingebettet werden, was wirklich kleine PDF unmöglich macht. List&Label bettet die vollständige Schriftart ein, andere PDF-Tools nur einen Teil der Schriftart. Daher kommt der Größenunterschied. Daran ändert sich auch bei der nächsten List&Label-Version nichts. (Ich bezweifle übrigens, dass die obigen PDF mit 32KB durch ein PDF/A-Validierungstool laufen würden - bei 32KB ist es sehr unwahrscheinlich, dass die notwendigen Schriftarten eingebettet wurden.)

Insofern: Wer kleine PDF-Dateien möchte muss das aktuell global in der Wawi aktivieren indem er PDF/A abschaltet. In der Wawi 1.4 oder 1.5 wird diese Option zusätzlich auch die L&L-Einstellungen übernehmen (Quasi: PDF/A global an, PDF/A global aus und PDF/A aus der Vorlage nehmen) - dann bekommt man sehr kompakte PDFs die sich z.B. für den Mailversand eignen (aber unter Umständen auf den Zielsystemen nicht perfekt angezeigt werden, wenn man exotische Schriftarten verwendet).

Gruß,
Sebastian

 

[Petuchov]

Hi,

...Ich bezweifle übrigens, dass die obigen PDF mit 32KB durch ein PDF/A-Validierungstool laufen würden - bei 32KB ist es sehr unwahrscheinlich, dass die notwendigen Schriftarten eingebettet wurden

File exportPDFRECHNUNG2.pdf
Compliance pdf1.4
Result Document validated successfully.

.....dass die notwendigen Schriftarten eingebettet wurden
Schriftarten (die Begrenzung auf die verwendeten Zeichen ist erlaubt

PDF/A-2b: Mindestanforderung an eine PDF/A-2 Datei, garantiert das richtige Erscheinungsbild des Dokuments für eine Langzeitarchivierung.
PDF/A-3 eröffnet Möglichkeiten für Elektronische Rechnungen, da mit diesem Standard in einer Datei sowohl die maschinenlesbaren Daten im XML-Format hinterlegt werden können als auch die archivtaugliche PDF-Ausgabe der Rechnung. Im Juni 2014 wurde der ZUGFeRD-Standard veröffentlicht, der auf PDF/A-3 aufsetzt.

PDF/A-3 ist, wie auch PDF/A-1 und PDF/A-2, ein spezielles Unterformat von PDF. Die PDF/A-Formate können für Zwecke der Langzeitarchivierung verwendet werden. Die Besonderheit von PDF/A-3 ist, dass bei dieser Spezifikation beliebige andere Dateien in die PDF/A-Datei eingebettet werden können, also auch XML-Dateien.

ZUGFeRD: Darin wurde durch eine Änderung des § 14 des Umsatzsteuergesetzes die elektronische Rechnung der klassischen Papierrechnung gleichgestellt. Zuvor musste der Empfänger die Echtheit und Unversehrtheit des Dokuments gegenüber dem Finanzamt durch Nachweis eines qualifizierten digitalen Zertifikates belegen können. Als Alternative zur qualifizierten Signatur sind nun sogenannte „innerbetriebliche Kontrollverfahren“, die einen „verlässlichen Prüfpfad“ zwischen der Rechnung und der Lieferung gewährleisten, zulässig. Hinter dieser Definition verbirgt sich im Grunde eine klassische Rechnungseingangsprüfung, die in jedem Unternehmen ohnehin praktiziert werden muss
§ 14 Abs. 1 Satz 7 UstG schreibt jedoch weiterhin vor, dass Rechnungen nur elektronisch übertragen werden dürfen, wenn der Empfänger diesem vorher zugestimmt hat.


Eine ZUGFeRD-Rechnung besteht im Wesentlichen aus zwei Teilen: Aus einer visuellen Darstellung der Rechnung für den Menschen und aus maschinenlesbaren strukturierten Daten. Die visuelle Darstellung der Rechnung erfolgt in Form von PDF/A-3. Die maschinenlesbaren strukturierten Daten im XML-Format werden dem PDF/A-3 als Anhang beigefügt. Somit dient das PDF als Container sowohl für die visuelle Darstellung als auch für die strukturierten Daten im XML-Format.

Um elektronische Rechnungen mit ZUGFeRD-Standard zu erzeugen, auszulesen und weiterzuverarbeiten, wird entsprechende Software benötigt.

Im Gegensatz zu anderen Verfahren wie EDIFACT stellt die ZUGFeRD-Spezifikation keinerlei Anforderungen an die Übertragung der Rechnungen. Die ZUGFeRD-Rechnungen können so ausgetauscht werden, wie es für die beiden Vertragspartner am sinnvollsten ist. Anders als bei EDI Verfahren muss bei ZUGFeRD zwischen den beiden Parteien im Vorfeld des Rechnungsaustausches keine Vereinbarung getroffen werden. Aufgrund der Änderungen im Steuervereinfachungsgesetz 2011 darf ein Rechnungssender bis auf Widerruf elektronische Rechnungen versenden.

 

[chx_de]

Hi,

also nach einigen Tests, ergibt sich folgendes Bild.

Unsere Rechnungen sind sehr einfach gehalten. Keine Logos, nur Arial, nix exotisches.

1. Speichern aus JTL (LL) ohne PDF/A --> 8kb
2. Seichern aus JTL (LL) mit PDF/A --> 199 kb
3. Drucken aus JTL mit dem ecoDMS PDF/A Drucker --> 28kb

Habe ich das richtig verstanden, dass ecoDMS bei der Archivierung auf jeden Fall ein PDF/A erzeugt? Ich habe das PDF aus Variante 1 (also mit 8kb) in den scaninput Ordner gespeichert. Dann eine automatische Klassifizierung laufen lassen. Das Dokument ist immer noch 8kb groß. Ich meine aber irgendwo im großen Handbuch gelesen zu haben, dass eine weitere Version in der Datenbank gepeichert wird. Ist das so?

 

[wawi-dl]

Teste doch mal was ecoDMS macht ...
schiebe eine PDF mit und ohne LZA rein, dann exportiere beide PDFs mal.

Meine ersten Tiffs die ich damals importiert habe, werden als PDF/A exportiert.
Die aktuelle Datenbank hat 7GB, da möchte ich gerade nicht herumspielen, da alle Dokumente mit PDF/A importiert werden, auch SCANs per Doku-Scanner.

 

[chx_de]

Habe ein normales PDF in das ecoDMS importiert und dann aus dem ecoDMS wieder exportiert.

--> wird kein PDF/A

Jetzt muss ich mich einfach für mich entscheiden

a) die normalen PDF einfach über einen Workflow in den scaninput Ordner speichern --> das wäre bestimmt eine schnelle Lösung
b) die Rechnungen über einen Workflow über den ecoDMS PDF/A Drucker dem System hinzufügen --> hätte ich kleine PDF/A aber das dauert bestimmt.
c) per Workflow die von LL erstellten PDF/A exportieren und dann wie auch immer (mit diversen Tools * Adobe Distiller habe ich sogar noch Version 8) nacharbeiten. Dann erst in den ecoDMS scaninput Ordner kopieren.

Muss ich mir noch mal durch den Kopf gehen lassen.

Aber auf jeden Fall werde ich mir ecoDMS final installieren und ein paar Lizenzen kaufen. Super Software. Danke für den Tipp hier im Forum!

 

[ag-websolutions.de]

b) die Rechnungen über einen Workflow über den ecoDMS PDF/A Drucker dem System hinzufügen --> hätte ich kleine PDF/A aber das dauert bestimmt.

Welche zeitliche Einbuße befürchtest du?

Habe ein normales PDF in das ecoDMS importiert und dann aus dem ecoDMS wieder exportiert.
--> wird kein PDF/A

Korrekt .. siehe Handbuch ...

ecoDMS legt die archivierten Dateien stets im Originalformat ab. Die zusätzliche Umwandlung von beispielsweise
Office-Dokumenten oder E-Mails in ein PDF/A erfolgt ausschließlich bei einer Archivierung über das jeweilige ecoDMS
Plugin / Addon.

 

[chx_de]

Welche zeitliche Einbuße befürchtest du?

Ich dachte nachts mit einem Workflow ca. 100 Rechnungen "speichern" würde vielleicht schneller gehen, als diese alle zu drucken.
Ist aber wahrscheinlich auch quatsch

Ich werde das testen und mich dann bezüglich Lizenz bei dir melden.

Ich muss dann nur noch die Leistung vom Server hochsetzen, da sonst die Wawi extrem langsam wird. Aber das läuft ja zur Zeit alles noch auf minimal Einstellung zum testen.

 

[wawi-dl]

Muss mich mal korrigieren, wir arbeiten aktuell mit 2 Archiven, einer lokalen Festplatte (mit zusätzlicher PDF-Ablage in der Cloud, für schnellen Zugriff Kollegen und Steuerberater), sowie per ecoDMS Printer direkt ins ecoDMS.

Bei Erstellung einer Rechnung in der JTL Wawi, werden somit 2 Workflows angestoßen:
1. WF: Ausgabe per "Fax" mit "ecoDMS Printer", hierzu aber Blindtext für Klassifizierung notwendig -> PDF/A wird 140KB groß
2. WF: Ausgabe per "Speichern" als PDF über JTL-Wawi und List&Label selbst, Vorteil kein Blindtext enthalten -> PDF aber 260KB groß, in der Cloud aber egal


So, ich kann dir also nur noch mitgeben, dass wir die Erstellung von PDF's mit dem Versand machen, heißt es werden 10-20 Pakete jeweils vom Bearbeiter erstellt.
Bis die Etiketten gedruckt sind, sind bei uns auch die PDF's erzeugt und archiviert, klappt also an Performance sehr gut.
Ich glaube auch nicht, dass du gleich 100 Rechnungen los schießt oder? Selbst wenn macht die Warteschlange ja den Rest.

 

[chx_de]

Hi,

ich würde es wie in 1) machen und ob ich dann noch 2) mit hinzunehmen, muss ich mal sehen.

Da sich hier aber das Thema weit von der PDF Größe entfernt hat und sich im Moment mit ecoDMS beschäftigt, habe ich dazu mal einen neuen Thread eröffnet. Ich denke, dann haben andere User, die sich für ecoDMS interessieren ggf. auch etwas davon.

https://forum.jtl-software.de/threads/ecodms-einrichten.97859/

 

[wawi-dl]

Es gibt schon einen Thread dazu

 

[Stephan K.]

Hi,

gibt es noch eine dritte Einstellung, die ich übersehen habe?
Ich habe PDF/A in den globalen Einstellungen und auch im Projekt deaktiviert, aber ob mit oder ohne PDF/A, es ist immer die selbe Größe...

Langfristig möchte ich auch ein Programm drüberlaufen lassen, um die PDF/A zu verkleinern, aber dazu muss es ja erstmal einen Unterschied machen, ob ich mit oder ohne nutze.
Kann man dem Kunden auch eine verkleinerte Rechnung zusenden? Geht das nur über die globale Nachbearbeitung (PDF-Einstellungen, L&L)?

 

[gutberle]

@charlyhahn : Danke für die ausführliche und exakte Darstellung. Es gibt auch noch einen anderen gewichtigen Grund, warum man neben der Dateigröße der eigenen Rechnungen auch auf den Inhalt achten sollte, nämlich die Sicherstellung der Persistenz der Daten in der Wawi, ich hatte das hier schon einmal beleuchtet und für mich hat der Punkt noch überhaupt nichts an Brisanz verloren. List & Label kann übrigens schon jetzt Zugferd Rechnungen erzeugen und benutzt dazu das intarsys Toolkit.

Ich will mit diesem Kommentar nicht die hier geführte, sehr interessante Diskussion über PDF kleiner, kleiner, kleiner sprengen, aber nach 4 Seiten Posts und Meinungen zu "<1 kB muss doch zu schaffen sein" wird es meines Erachtens Zeit, dass auch die andere Seite, nämlich die Möglichkeit zur elektronischen Rechnungsverabeitung von Eingangs- und Ausgangsrechnungen, die saubere Implementierung echter Datenpersistenz in der Wawi und zuletzt auch die Umsetzung der GoBD, usw., auch einmal beleuchtet wird. All das beißt sich nämlich integral mit dem Wunsch nach extrem kleinen PDF und braucht zwingend PDF/A-3.

Nachtrag: Ich habe gerade entdeckt, dass List & Label ab der Version 21 PDF/A-3 ZUGFeRD Rechnung völlig ohne externe Tools selbst erzeugen kann. Noch einfacher, noch besser...

 

[radonshop]

Jepp, wird umgewandelt ...

Nochmal, schau dir DATEV UO auf jeden Fall genau an! Jetzt nur mal ein Beispiel, ohne die Preise nachzuschauen, um die Rechnung zu verstehen:
1. Jahr ... 20 GB ... 50 EUR/Monat
2. Jahr ... 40 GB ... 75 EUR/Monat
3. Jahr ... 60 GB ... 100 EUR/Monat
4. Jahr ... 80 GB ... 125 EUR/Monat
5. Jahr ... 100 GB ... 150 EUR/Monat
....
10. Jahr ... 200 GB ... 275 EUR/Monat

Heißt, du würdest ab dem 10. Jahr dann monatlich schon 275 EUR bezahlen, die Kosten steigen und steigen also jährlich, das ist krank.
Da amortisiert sich ein eigener Server + DMS-System schon sehr schnell.

Da hast du schon recht, was die Kosten angehen. Aber man darf natürlich nicht vergessen, dass der Steuerberater die teuerste "Komponente" in der Kette ist.
D.h. wenn er die Daten per JTL2Datev bekommt und dann stichprobenartig 10 Rechnungen kontrollieren will, bzw. die ein oder andere Rechnung prüfen will, muss er sich in das ecoDMS einloggen, die Rechnung suchen, öffnen, prüfen...dauert die ein oder andere Minute. (wir nutzen ecoDMS nicht..und daher wissen wir auch nicht wirlich, wie das händling ist)

Wenn man jedoch UnternehmenOnline nutzt, ist die Rechnung direkt mit dem Buchungssatz verknüpft. D.h. ein Doppelklick und der Steuerberater kann die Rechnung prüfen.
Unser Berater kostet 90 Euro pro Stunde, d.h. jede Minute kostet uns 1.50 Euro.


p.s. wir nutzen im Moment JTL2Datev aber unser Steuerberater hat uns jetzt das UnternehmenOnline ans Herz gelegt.