E-Rechnung

[HolgerX]

Hmm..

Zitat:

Zitat von himitsu (Beitrag 1542415)

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.

Aber dennoch müsste er dieses zunächst in sein Programm einprogrammieren.
Und genau dass möchte er ja nicht, weshalb er es mit einem Drucker (Papier ging schon immer) versucht.

[Frickler]

Zitat:

Zitat von HolgerX (Beitrag 1542414)

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.

Sein Workflow:
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.

[HolgerX]

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

[Frickler]

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.

[himitsu]

PS: In einen 64 Bit Windows läuft kein DOS-Programm mehr. (das 16 Bit-Subsystem fehlt)

[Olli73]

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.

[khh]

Zitat:

Zitat von Frickler (Beitrag 1542424)

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.

das alte Programm ist ein Windows-Programm

[khh]

[QUOTE=Frickler;1542417]

Zitat:

Zitat von HolgerX (Beitrag 1542414)

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.

die Idee ist gut, so könnte das funktionieren!

[Ulf346C]

Kann mir jemand etwas zum geforderten XML Format sagen ?
Stehe da total auf dem Schlauch

[khh]

Zitat:

Zitat von Olli73 (Beitrag 1542429)

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.

ja gibt es, das ist auch ne Variante.