Dummy-Drucker

1. offizieller Beitrag

    Hi,

    ich hatte das Thema in der SB ja schon mal angeschnitten, aber es wohl wirklich zu umfangreich, um dort geklärt zu werden. Daher nochmal hier.

    Mein Problem

    Wir benutzen seit dem 24.09.2018 ein neues ERP-System, welches komplett im Browser (bei uns generell Chrome) läuft und beim Anbieter gehostet wird. Das heißt, Modifikationen direkt am ERP-System sind nicht möglich. In diesem ERP-System erzeugen wir sämtliche Belege als PDF-Dateien, also (u.A.) Auftragsbestätigungen, Lagerbelege (Kommissionierzettel), Lieferscheine und Rechnungen. Da wir aber keine klare Trennung zwischen unseren Büroabteilungen haben, nimmt eigentlich jeder Mitarbeiter Aufträge telefonisch entgegen und schreibt auch gleichzeitig Lieferscheine und Rechnungen. Die Problematik liegt jetzt beim Drucken der so erzeugten Belege. Alle Rechnungen und Lieferscheine werden auf Drucker A im Büro gedruckt, bestückt mit unserem Briefbogen. Alle Lagerbelege werden auf Drucker B im Lager gedruckt, damit die Kommissionierer diese direkt von dort bearbeiten können. Und - wie sollte es anders sein - wird natürlich regelmäßig vergessen, den richtigen Drucker zu wählen.

    Bisheriger Lösungsansatz

    Aus eigenem Antrieb und auf Anraten einiger User hier habe ich versucht, den Umweg über einen PDF-Drucker zu nehmen (in meinem Fall 7-PDF). Das sollte wie folgt funktionieren: Die Damen drucken IMMER auf dem PDF-Drucker, dieser schmeißt den Ausdruck als PDF immer ins selbe Verzeichnis. Dieses Verzeichnis wird dauerhaft von einem AutoIt-Skript überwacht, welches anhand des Dateinamens den Druck auf dem richtigen Drucker anstößt. Das ist schon relativ umständlich, finde ich. Erschwert wird das ganze noch durch die Tatsache, dass der PDF-Drucker nicht den Original-Dateinamen weitergeben kann. Ich habe also im Moment folgende (lauffähige) Konstruktion: ERP -> PDF-Drucker -> AutoIt-Skript -> xpdfs pdftotext (Rausfinden des Belegtypes) -> Sumatra-PDF (stilles Drucken). Das sind also alleine schon drei externe Softwarekomponenten PLUS mein Skript. Ich hätte da gerne eine standsicherere und elegantere Lösung, um ehrlich zu sein.

    Vom Wunschdenken her wäre ein Dummy-Druckertreiber das Mittel der Wahl. Oder ein Chrome-Plugin, welches den Drucker passend wählt. Oder, oder, oder... Es gibt sicherlich einige Möglichkeiten. Aber ich habe noch nichts anderes realisiert bekommen, mal von der bereits genannnten Lösung abgesehen. Fällt noch jemandem was ein?

    Naja kenne deine PDF Drucker Lösung nicht. Wir verwenden teilweise FreePDF. Damit ist es möglich Vor- und Nachgestellte beliebige Scripte zu definieren. Ob dabei der Originaldateiname durchgeschleift werden kann weiß ich gerade nicht, ich denke aber das sollte möglich sein. Sofern das passt kannst du dir zumindestens den Zwischenschritt "Parsing" der PDF schenken, bzw. das auf Auswerten des Dateinamens minimieren. Stilles Drucken oder zur Not Dialog-Automatisiertes Drucken ist evtl. auch via Autoit möglich, somit kann theoretisch auch Sumatra-PDF aussortiert werden. Ideal wäre aber wohl der Weg über ein Browser Plugin oder wie schon erwähnt ein "eigener Dummy Drucker". Weniger aufwendig sind die Lösungen dann aber auch nicht, da du eher nichts fertiges hierfür finden wirst.

    Ganz simpel wäre es evtl. den Standard PDF Betrachter im Browser umzubiegen oder abzuschalten und stattdessen einen Download der Datei zu erzwingen. Dann müsste nur der Downloadordner des Users überwacht werden.

    • Offizieller Beitrag
    Zitat von chesstiger

    Erschwert wird das ganze noch durch die Tatsache, dass der PDF-Drucker nicht den Original-Dateinamen weitergeben kann.

    Was meinst du, mit "nicht weitergeben kann"?

    Der Dateiname wird für die PDF-Erstellung aber schon genutzt (aus Bsp. 'RE0815.doc' wird 'RE0815.pdf')? Das machen zumindest alle PDF-Printer die ich verwende (FreePDF, PDFCreator) automatisch. Und zum physischen Druck selektierst du doch anhand dieses Namens den Drucker und stößt den Jab an. Da ist doch nichts mehr weiterzugeben - oder verstehe ich das falsch?

    Gegen ein Browser Plugin spricht meiner Meinung nach übrigens, dass sich Browser viel zu schnell verändern. Siehe Problematik bei Firefox und der überarbeiteten Plugin API. Ob Chrome in der jetzigen Form in 5-10 Jahren überhaupt noch existiert kann man heute auch schlecht abschätzen.

    Zitat von BugFix

    Der Dateiname wird für die PDF-Erstellung aber schon genutzt (aus Bsp. 'RE0815.doc' wird 'RE0815.pdf')

    Es gibt beim Druckvorgang kein kein "RE0815.bla-Dokument"! Da wird eine Seite an einen Drucker gesendet, genau DAS ist ja sein Problem! Leitest du dann auf einen PDF-Drucker um, fragt dieser dann "natürlich" nach dem Dateinamen oder nimmt den "Standard"-Dateinamen, der meist irgendwo hinterlegt werden kann (im PDF-Druckertreiber....)

    chesstiger

    Ich löse das Problem bei uns in der Firma folgendermaßen:

    Die ins System an diesem Tag eingegebenen Aufträge werden 1-2x am Tag "abgearbeitet". Ich habe das Glück, die ERP-Systemdatenbank anzapfen zu können, da hole ich mir erstmal alle "neuen" Aufträge, die dann nacheinander abgewickelt werden. Von der Erstellung und Überspielung von Maschinendaten bis zum u.a. "drucken" von PDF´s läuft alles über EIN AutoIt-Script, welches die ERP-Anwendung komplett für den jeweiligen Vorgang fernsteuert.

    Die PDF´s werden dabei je nach Ziel (AB,LS, RE usw.) mit Auftragsnummer und ggf. weiteren Infos im Dateinamen abgespeichert.

    Dabei erkennt mein Script "automatisch" (die Scriptsprache heißt ja Auto :o) It , sorry, DER musste jetzt sein^^) den aktuellen Zustand des Auftrags.

    Auftrag wurde erfasst -> Alle Systemdaten erstellen und Maschinendaten und Listen für die Produktion erstellen

    Auftrag wurde gefertigt -> Packlisten und Ladelisten erstellen

    Auftrag wurde Kommissioniert -> Bereit zur Auslieferung

    Auftrag wurde ausgeliefert (LS wurde erstellt) -> Info an Buchhaltung für Rechnungserstellung (mit anschließender "automatisierter" Rechnungserstellung)

    Wenn du keinen Zugriff auf die Datenbank hast, wirst du wohl schlechte Karten haben.

    Ansonsten greifst du dir die aktuellen laufenden Aufträge und machst mittels Script genau das, was der Mitarbeiter machen würde....Buttons klickern....

    Und da du ja den Status weißt, bzw. auch das von einem Script zur Not vom Mitarbeiter abfragen lassen kannst, brauchst du "nur noch" die richtigen "Knöpchen drücken"

    Die Mitarbeiterin, die den Auftrag erfasst hat und jetzt einen Lieferschein drucken will, drückt nun nicht mehr im ERP-Programm 19 Buttons (bei uns ist das so, DAS war der Grund, mein Script anzufangen...) sonder startet bspw. dein Script per Hotkey und wählt dort "LS drucken" und guckt die 5 Sekunden zu, wie das Script klickert und IMMER den richtigen Drucker wählt.

    • Offizieller Beitrag
    Zitat von Andy

    Es gibt beim Druckvorgang kein kein "RE0815.bla-Dokument"!

    OK, da bin ich dann von unserer knapp 20 Jahre alten WaWi-Software verwöhnt. Ich lasse jeden Ausdruck (unabhängig davon, welcher Drucker/Druckformat gewählt wird) parallel als PDF ausgeben (für meine ELO-Archivierung) und das erledigt die WaWi von allein mit "Belegtyp_BelegNr.pdf". Ich habe allerdings schon in der Reportvorlage definiert, welcher Report an welchen Drucker ausgegeben wird. Die Reports haben eine rudimentäre Basic-Schnittstelle mit einer Anweisung ::BeforePrint, die es ermöglicht z.B. Drucker belegtypabhängig zuzuweisen. Diese Flexibilität habe ich extra gesucht, als ich die Software gekauft hatte. Von Updates habe ich aber Abstand gehalten, denn diese verschlimmbessern eine Software erfahrungsgemäß. In der aktuellen Softwareversion könnte ich kaum noch automatisiert zugreifen.

    Korrekt, beim Namen liegt ein großes Problem der Sache. Ich habe einige PDF-Drucker getestet, bekomme als Originaldokumententitel allerdings immer "PDF.js" (der Name des Chrome-internen PDF-Viewers). Daher die Notlösung, mit pdftotext im Dateiinhalt zu schauen.

    Andy

    Eine Automatisierung des ERP-Systems ist grundsätzlich möglich, klar. Allerdings handelt es sich um ein Rolling-Release-System (mehrere Updates pro Woche), welches auch noch beim Anbieter gehostet wird. Das heißt, ich habe praktisch keine Möglichkeit, Updates zu verhindern. Eine Automatisierung der Oberfläche bedeutet daher extrem viel Wartungsaufwand. Der Aufwand als solches hält sich bei uns allerdings in Grenzen. Mitarbeiterin steht im Lieferschein, klickt auf das kleine Drucker-Icon => PDf-Vorschau des Beleges wird angezeigt, Systemdruckdialog plopt automatisch auf. Wenn der richtige Drucker bereits ausgewählt ist, reduziert sich der Aufwand also auf 2 Klicks, was ich für okay halte.

    BugFix

    Ja, unsere Damen sind an dem Punkt auch sehr verwöhnt. IBM AS/400 und textbasierte Warenwirtschaft lässt grüßen. Bisher haben die Damen den entsprechenden Druckbefehl eingegeben (bspw. drucke LS 5344 oder drucke alle noch nicht gedruckten Rechnungen), dann hat das System selber entschieden, welchen der Drucker es angesteuert hat (Nadeldrucker für LS, Nadeldrucker für RE, Laserdrucker für Protokolle). Die meisten unserer Bürodamen empfinden die manuelle Druckerauswahl also als extremen Rückschritt.

    Generell haben wir auch ein Problem damit, herauszufinden, ob ein Beleg wirklich gedruckt worden ist. In der AS/400 wusste das System genau, ob der Job schon an den Drucker weitergeleitet worden ist (Ansteuerung über TwinAx-Kabel). Im neuen ERP geht das natürlich nicht, der Browser bekommt ja keine Rückmeldung. Und wenn eine Dame sich beeilen wollte und u.U. den Druckdialog NACH Erzeugung der PDF abgebrochen hat, wird der Beleg trotzdem als gedruckt markiert. Da verliert man bei >400 Lagerbelegen am Tag schon mal die Übersicht, dann geht auch was verloren. Dafür habe ich auch noch keine elegante Lösung.

    Schonmal geschaut was Adobe Acrobat als Dateiname übergibt?

    Andy hat mir ein Schnitzel gebacken aber da war ein Raupi drauf und bevor Oscar das Bugfixen konnte kam Alina und gab mir ein AspirinJunkie.