|
E-Rechnung
hallo zusammen,
ich möchte zur Erstellung einer E-Rechnung einen Druckertreiber erstellen, der anstatt des Standarddruckers ausgewählt werden kann. So kann ich mir den Eingriff ins Druckprogramm der Software sparen. Jemand ne Idee? Ich danke euch. |
AW: E-Rechnung
An sich eine gute Idee, nur irgendwie muss man dem PDF-Drucker ja das XML-File übergeben, welches mit in die PDF integriert werden soll. Das können nicht mal die üblichen PDF-Drucker am Markt.
|
AW: E-Rechnung
Ich vermute, deswegen will er ja gerade einen Druckertreiber erstellen. Leider ist das Erstellen eines Treibers in Delphi alles andere als trivial.
|
AW: E-Rechnung
Man müsste erstmal 'nen Standard durchsetzen, wie man solche Zusatzdaten im Datanstom an Drucker(Treiber) mitgeben könnte.
Oder man baut sich oder lässt bauen, einen speziellen Druckertreiber, bei dem das möglich ist und wenn es mit diesem einem Treiber Probleme gibt, ist man am Arsch. Oder man druckt erstmal und fügt das nachträglich in die PDF ein, aber dafür benötigt man dann eine Komponente, welche PDF bearbeiten kann und wenn man sowas schon hat, dann kann man die PDF gleich direkt erzeugen und spart sich externe Abhängigkeiten. |
AW: E-Rechnung
Zitat:
Ich möchte halt vermeiden ein seit 15 Jahren fehlerfrei laufendes Programm anzufassen. Dem Kunden trotzdem zu ermöglichen die gesetzlichen Anforderungen an die Ausgabe von E-Rechnung zu erfüllen. Noch irgendwelche Ideen? Muss ja auch nicht unbedingt alles in Delphi /Lazarus sein. |
AW: E-Rechnung
Zitat:
|
AW: E-Rechnung
Was wird denn zum Drucken verwendet (Report-Generator, TPrinter, ...)?
|
AW: E-Rechnung
man könnte jeden beliebigen PDF Drucker nehmen und die PDF dann "manuell" mit der XML verbinden. Je nachdem wie viel Rechnungen so im Monat geschrieben werden, wäre das für ältere Softwareprodukte möglich.
|
AW: E-Rechnung
Ich meine FastReport hatte da mal eine Anleitung, wie nach einer PDF-Erstellung die XML-Datei via Programmcode angehängt werden kann...die xml-Datei muss aber vorher erstellt werden. In der Vollversion gibt es ein "zugferd demo project".
Hartmut |
AW: E-Rechnung
Zitat:
Zur Erstellung der XML-Daten muss ich die "normale" Druckausgabe auslesen und verarbeiten. Die Struktur der Rechnung ist mir ja bekannt, deshalb die Idee über einen Druckertreiber zu arbeiten. Das alte Programm anfassen zu müssen, will ich vermeiden. |
AW: E-Rechnung
Zitat:
|
AW: E-Rechnung
Zitat:
|
AW: E-Rechnung
Zitat:
|
AW: E-Rechnung
Das ist ja die Grundidee, die von 7-PDF realisiert wurde.
 https://www.7-pdf.de/zugferd-pdf-erstellenDie Scannen die PDF-Datei nach einer Markierung, und wenn sie dann eine dazu passende XML finden, fummeln sie beides zusammen. Soweit die Theorie. Das klingt auch für mich zunächst mal ganz charmant, ich wollte mir das bei Gelegenheit mal ansehen, weil dies - wenn es denn zuverlässig funktioniert - eine sehr einfache Lösung wäre, diesen Export nachzurüsten. Wenn auch zum Preis dieser externen Abhängigkeit zu 7-PDF. |
AW: E-Rechnung
[QUOTE=Papaschlumpf73;1542356]
Zitat:
ich muss auf jeden Fall die Daten aus der Druckausgabe auslesen, wenn ich am Programm nix verändern will. Was ich danach mache ist ja zweitrangig. |
AW: E-Rechnung
Zitat:
Aber der Ansatz ist schon der den ich brauche. Hab mir das jetzt angeschaut. Kann ich aber nicht gebrauchen, da wird das fertige XML erwartet. Gerade das will ich aber aus der Rechnung auslesen. |
AW: E-Rechnung
Früher gabs mal ein Tool namens "RedMon", damit konnte man eine Druckausgabe auf einen virtuellen Drucker an ein beliebiges Programm weiterleiten. Das läuft aber leider nur bis Windows 7.
Auf der Suche danach fand ich folgendes: https://en.wikipedia.org/wiki/List_o...inter_software. Vielleicht hilfts weiter. |
AW: E-Rechnung
Zitat:
|
AW: E-Rechnung
Hmm..
Zitat:
http://www.ghostgum.com.au/software/redmon.htm ) läuft auch unter Windows 11 problemlos...Er wurde nur nach Win7 nicht weiterentwickelt, jedoch scheint sich da bei MS nichts geändert zu haben. Das Problem mit XML und 'Druckertreiber' ist nur, dass Drucker unter Windows generell die Rechnung auf Papier bringen und 'Papier' keinen Speicher für XML hat ;) Somit kann einem regulären Druckertreiber auch kein XML mitgegeben werden. Die Umleitung des Ausdruckes in eine PDF ändert hier nichts. Nur wenn deine Applikation selber direkt das PDF erzeugt (ohne Umweg über Drucken!), kann diese dann das XML dazu packen. Oder es muss ein ganz spezieller Drucker in einer Skriptsprache angesprochen werden, aber auch hier müsste deine Applikation die Skriptsprache einprogrammiert bekommen. Die einzige Option, welche mir hier einfällt, ist folgendes: - Redmon (für den Port) - Druckertreiber für einen PostScript-Drucker verwenden. - Die Roh-Daten (von Redmon an dein Tool geliefert) parsen -> aus den PostScriptdaten (wenn vorhanden) das XML-Dokument erzeugen -> Weiterleiten, z.B. an GhostScript (Achtung Linzenz!) -> Dann das durch GS erstellte PDF um das XML-Dokument erweitern (wie und wo dies ins PDF gehört ???? k.a.) |
AW: E-Rechnung
Ginge schon .... der Könnte das XML ja via MicroDots auf der Seite verstecken, so, wie er heimlich seine ID versteckt (damit die Polizei weiß, dass du den Erpresserbrief geschrieben hast)
Es ging ja erstmal um einen Standard, damit sämtliche Druckertreiber sowas bekommen könnten ... ob sie es dann nutzen oder nicht, war erstmal egal, Hauptsache alle Treiber, welche es den Druck irgendeine Datei umleiten, würden die selbe Methode benutzen. |
AW: E-Rechnung
Hmm..
Zitat:
Und genau dass möchte er ja nicht, weshalb er es mit einem Drucker (Papier ging schon immer) versucht. |
AW: E-Rechnung
Zitat:
1) alte Software druckt eine Rechnung nach RedMon 2) RedMon leitet den Druck in ein Utility um, was er noch schreiben muss 3) Dieses Utility extrahiert die Rechnungsinformationen aus dem Ausdruck (EMF Datei) zum einen als XML und zum anderen als PDF, und fügt beides zusammen, und speichert das Resultat weg. Das dürfte ganz schön hart werden! Nachtrag: Warum nicht so: 1) Rechnung drucken auf einen PDF-Drucker, der einen automatischen Dateinamen vergeben kann, in einen vorgegebenen Ordner 2) Auf dem Ordner eine Ordnerüberwachung mit eigener Software 3) diese Software lauert auf neue PDFs, scannt die, holt die Infos raus, macht ne XML und hängt die an. Am Ende mit passendem Namen in passenden Ordner speichern. |
AW: E-Rechnung
Hmm...
Vom Prinzip her sind beide Workflows ähnlich, nur dass er bei Option 2 für die Erstellung des PDF-Dokumentes einen beliebigen PDF-Drucker verwenden kann. Die Software für Option 1 oder 2 mit dem Parser muss er auf jeden fall selber erstellen. Bei Option 1 kann direkt auf die Original PostScript Daten zugreifen, bei Option 2 muss er sie aus dem PDF-Format heraus holen. Meiner Meinung nach hat er mit Option 1 mehr Sicherheit, da der User bei Option 2 das Format des PDF (Print/EMail/Kompatiblität) jederzeit im Druckertreiber verändern kann. Beides ist aufwändig... |
AW: E-Rechnung
P.S.: Für den Fall, dass das "alte Programm" ein DOS-Programm ist mit eigenen "Druckertreibern": es gibt auch "GhostPCL", damit kann man eine PCL Ausgabe(datei) in PDF umwandeln.
|
AW: E-Rechnung
PS: In einen 64 Bit Windows läuft kein DOS-Programm mehr. (das 16 Bit-Subsystem fehlt)
|
AW: E-Rechnung
Es wird doch bestimmt eine Datenbank verwendet?
Ich würde es dann so machen, wie im Beitrag #22 von Frickler im Nachtrag beschrieben, aber die XML-Daten nicht aus der PDF sondern aus der Datenbank erstellen. |
AW: E-Rechnung
Zitat:
|
AW: E-Rechnung
[QUOTE=Frickler;1542417]
Zitat:
|
AW: E-Rechnung
Kann mir jemand etwas zum geforderten XML Format sagen ?
Stehe da total auf dem Schlauch |
AW: E-Rechnung
Zitat:
|
AW: E-Rechnung
Zitat:
|
AW: E-Rechnung
In der DOSBox geht aber auch nicht alles.
Hardwarezugriffe und auch bezüglich Drucker braucht man öfters speziell angepasste DOSBOX-Varianten. Aber im Grunde wollte ich nur freundlich darauf hinweisen, dass es besser sein mag, sowas Altes eher versuchen loszuwerden / zu ersetzen. |
AW: E-Rechnung
Zitat:
|
AW: E-Rechnung
Zitat:
Dann bietet es sich an die Metadaten wie folgt beim Ausdruck einzubetten: 1) Start und Endmarken definieren, z.b. #${{{ }}}$# 2) dazwischen kommen dann die Nutzdaten, möglichst lange Zeilen. Nur ASCII Zeichensatz, Umlaute und gewünschte Zeilenumbrüche codieren! 3) Auf der letzten Seite der Rechnung diese Daten ausdrucken und zwar mit Schrifthöhe 1 und weißer Textfarbe 4) Die Rechnung ausdrucken, z.b. mit MS PrintToPDF In WPViewPDF PLUS kannst Du dann den Text der letzten Seite abrufen und verarbeiten, z.b. in die PDF einbetten. Die letzte Seite kann dann gelöscht werden. Alternativ den Text unter die erste Seite drucken. Das geht in Word mit einer Textbox die im Header platziert wird. Ich habe beides probiert mit Word, ausgegeben mit PrintToPDF und es war mit WPViewPDF PLUS in beiden Fällen möglich die Daten zu extrahieren. Hinweis: Bei manchen PDF Druckern könnte man auch die leerzeichen codieren, wenn sie beim Druck verloren gehen können. Ich finde es besser die Daten auf einer zu löschenden Seite zu platzieren, da die sonst bei der Anzeige noch anwählbar sind. Die Anzeige der PDF wird auch verlangsamt durch den vielen nicht sichtbaren aber gedruckten Text. |
AW: E-Rechnung
Zitat:
Danke dir für die Idee. |
| Alle Zeitangaben in WEZ +1. Es ist jetzt 22:01 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz