@Hauke_Hamann schrieb:
@Angelika_Roßmeisl schrieb:
Einen Text zu kopieren und in die Buchungszeile einzufügen halten wir ebenfalls für eine sinnvolle Funktion.
Jedoch ist aufgrund der umfangreichen Änderungen an der Viewer-Architektur, die dafür nötig wäre, aktuell keine Umsetzung geplant.
Geschrieben am 27.8.2021
W A R U M N I C H T ???
Falls sich die DATEV-Meinung noch in der ersten Hälfte dieses Jahrzehnts ändern sollte, könnte ich mir doch glatt vorstellen, dafür das Label „Digitaler Softwareanbieter“ zu vergeben.
Sonst eher nicht.
Das Warum ist doch schnell erklärt.
DATEV weigert sich seit Jahren beharrlich offene Standards zu verwenden und versucht mit alten und im Altertum bewährten Methoden zu Zukunft zu bewältigen. Die Marketingabteilung gibt den Funktionen einen neuen Namen und vermarktet es top. Die Bemerkung "Alter Wein in neuen Schleuchen" zieht sich durch die alte Newsgroup wie auch durch die Community wie ein roter Faden.
DATEV hat seine Digitalisierung voll auf dem tif Format aufgebaut, die Markierung der wesentlichen Rechnungsdaten basiert ja auf OCR Erkennung und Positionspeicherung. Eine regelmäßige Weiterentwicklung fand, wie üblich, nur bei absoluten Fehlern statt.
Mit der Zeit wurden die Scanner immer leistungsfähiger und die Hersteller setzten, auch aus Kostengründen, auf die am meisten verbreiteten Formate, das waren und sind nun einmal pdf und jpeg, einen tif Konvertierer wurde nicht mehr mitgeliefert. Dabei ist jpeg ein reines Bildformat und pdf ist ein wenig komplexer.
Das pdf Format ist im Prinzip ein Container in den alle Anteile für die Darstellung des Dokuments hineingelegt werden, die Grafiken (also Bilder) werden vektorbasiert und nicht als Bildpunkte (wie z. B. Bitmap) abgelegt. Die Erzeugung (nicht Umwandlung) eines pdf Dokuments kann jetzt auf 2 Wegen geschehen, dem Scan und dem Druck. Beide Wege führen zu unterschiedlichen Ergebnissen.
Der, hier in stark vereinfachter Darstellung, Weg des Drucks läuft zuerst über einen PostScript Druckertreiber der tatsächlich die im Dokument enthaltenen Bildanteile in vektorbasierte Beschreibungen erstellt, eine *.ps Datei kann daher direkt von der Betriebssystemkommandozeile auf den Drucker gesendet werden,der PostScript fähige Drucker verarbeitet diese Datei sofort. Was das die PostScript Datei erstellende Programm nicht macht ist, die Schriften in Vektoren umzurechnen, die Textanteile bekommen ihren Platz im Ausdruck zugewiesen und die Schriftart und der -schnitt werden benannt. Je nachdem ob die Schrift im Drucker installiert ist oder nicht wird die Schriftart in die PS Datei eingebunden oder nicht, das spart Platz. Auf die Besonderheiten wie Farbprofile etc. kann hier verzichtet werden. Adobe braucht jetzt noch ein Format für die Weitergabe und Datenaustausch welches für die Druckvorstufe geeignet war, was hier aber nicht wichtig ist. Es wurde das pdf Format als Container geschaffen. Das ZugFerD Format macht sich diese Containereigenschaft zu nutze und packt den xml Teil einfach Bestandteil in den Container.
Der zweite Weg ist der Scan. Der Scanner bzw. die Software legt, einfach gesagt, die in ein jpeg Format umgeandelten Rohdaten des Scanners in den pdf Container, fertig. Dieses jpeg Bild oder, bei mehreren Seiten, Bilder werden mit unterschiedlichen Verfahren komprimiert.
Das zum Verständnis vorweg.
Die OCR soll die Datei ja für eine automatisierte Verarbeitung vorbereiten. Dabei sind die Erstellungswege unterschiedlich zu beurteilen. Im Weg 1 sind eigentlich alle Daten vorhanden, für eine optimierte Weiterverabeitung braucht es die Daten innerhalb und zusätzlich außerhalb der pdf Datei in einer Datenbank, DMS oder Buchungsassistent (oder -automat) wollen ja nicht für jede Suche alle Dateien öffnen und lesen. Also werden bei der erzeugten Datei von der OCR Software nur die Grafiken 'erkennungsdienstlich' behandelt und der Rest schlicht kopiert.
Bei der eingescannten Datei kommt es darauf an inwieweit der Scanner (oder die installierte Software) schon eine OCR Erkennung durchgeführt hat. Wird das gemacht trägt die pdf Datei ein Set an Klarschrift in sich, falls nicht muss die OCR in der Kanzlei oder DATEV das erledigen. Diesen Schritt macht DATEV aber nicht!
Da DATEV in der eigenen OCR das pdf Dokument nicht verändert müssen die Anwender bei DMS und Buchungsassistent auf eine Menge Komfort verzichten.
DATEV müsste, um die die gewünschte Funktion des Kopierens zu realisieren, zum Einen wissen welcher Text sich wo im Dokument verbirgt. Bei den über den Weg 1 erstellten Dokumenten eigentlich gar kein Problem, bei dem Weg 2 nur machbar wenn die OCR Daten auch im Dokument gespeichert sind.
Hätte die Produktentwicklung jetzt ein optimales Produkt für den nutzer im Auge gehabt wäre eine entsprechende Funktion kein Problem gewesen, es gibt genügend DMS Produkte die mit ihren eingebauten pdf Viewern genau das machen. Bei der OCR Suche werden in der Datenbank die Begriffe ermittelt, nach diesen Treffern die Dokumente und im Viewer dann die Suchbegriffe markiert. Die Texte lassen sich dann markieren und kopieren.
Es ginge wenn es denn gewollt wäre. Bei DATEV ist es wichtig eine Funktion im Marketing groß herauszustellen, den Aufwand für den Anwendernutzen so gering wie irgend möglich zu halten
Deshalb
DATEV - Das Softwaremuseum.
„Einen guten Ruf erwirbt man sich nicht mit Dingen, die man erst machen will.“ - Henry Ford
