Wijzigingen Printen naar PDF

[Wouter Rijnbende]

M.i.v. heden zijn er een aantal wijzigingen doorgevoerd m.b.t. het Printen naar PDF (en opname in Kontakten).

Applikatie Parameter "Output Printfiles opslaan J/N " vervallen

Deze parameter was opgenomen om het opslaan van de output van printfiles te kunnen aktiveren, en waarna deze waarde als default werd gebruikt voor alle printfunkties. Ofwel, als hier Nee werd ingevuld werd het hele mechanisme van opslaan nooit getriggerd, werd hier Ja ingevuld dan werd ieder Shift-/Control F2 printje default opgeslagen maar kon per print het vinkje nog worden uitgezet.

De achterliggende gedachte van het opslaan van printjes onder een zelf definieerbare naam, was niet zo zeer "het opslaan" (99% van de prints zullen niet eens opgeslagen worden), maar het toe kunnen kennen van een naam aan het printbestand om vervolgens het printbestand onder die naam te kunnen mailen.

Opslaan was (en is) alleen mogelijk bij een Shift-/Control F2 print. Zodra er met Shift-/Control F2 een printje wordt geprint, zal nu standaard de vraag worden gesteld of het printje moet worden opgeslagen en waar.


Parameters Variabele Layout aangepast

Ook bij de parameters van de Variabele Layout is de rubriek "Output Printfiles opslaan J/N" komen te vervallen (ook hier geldt dat een Shift-/Control F2 print standaard met de vraag komt of het printje moet worden opgeslagen).

Tevens is rubriek "Output Printfiles opnemen in Kontakten J/N" gewijzigd in "Printje igv Email opnemen in Kontakten J/N".

Oude scherm:

In de vorige versie is het opnemen van een Variabele Layout print in de Kontakten op dezelfde wijze geïmplementeerd als het opslaan van de output van een printfile. E.e.a. was opgehangen aan de Shift-/Control F2 print, en vroeg per print én of de file moest worden opgeslagen én of de print in een Kontakt moest worden opgenomen.  Bij de Faktuurrun zelf werd er niets opgenomen in de Kontakten, immers, enkel de data die naar het scherm geprint werd wordt afgevangen; data die rechtstreeks naar de printer geprint wordt niet, dus zouden we niet iedere faktuur in de Kontakten aantreffen.

Het per print vragen voor opname in de Kontakten was echter nimmer de bedoeling; dit zou volledig automatisch moeten gebeuren.

Ook hier moeten we de achterliggende reden in gedachte houden: het emailen.

Stel dat we een Uitgaande Faktuur printen, dan hebben we een versie op papier, welke we in een dossiermap zouden kunnen opslaan (even los van het feit dat we de Faktuur geprint hebben om deze op te sturen, en er alsnog niets in een map opgeslagen wordt).  Van een Faktuur die als email verzonden wordt hebben we verder helemaal geen bewijs dat deze verzonden is (hooguit misschien de automatische BCC die tijdens het mailen verzonden wordt) en dus is het daar juist gewenst om het document in de Kontakten op te kunnen nemen, opdat iedereen kan zien dat er een exemplaar per mail verzonden is.

Per heden is rubriek "Opnemen als Kontakt J/N" dan ook gewijzigd in "Printje igv Email opnemen in Kontakt J/N". Opname in Kontakt is dan ook alleen mogelijk indien het om een type Variabele Layout gaat welke "gemaild" kan worden; op dit moment: Inkooporders, Opdrachtbevestigingen en Fakturen.

Nieuwe scherm:

Scherm "Opslaan Shift-/Control F2 Printfile" ingekort

Met dat er niet meer per print mag worden gevraagd om opname in Kontakten, is onderstaand scherm

nu ingekort tot:

Het popup verschijnt overigens alleen indien in de parameters werd aangegeven in welke directory de output van printfiles moet worden opgeslagen; is deze parameter niet ingevuld, dan verschijnt dit popup niet.


Andere volgorde v.w.b.  methode "Opslaan Shift-/Control F2 Printfile"

Naar aanleiding van topic http://ha1.heartprofit.nl/profit/index.php?topic=22498.msg34649#msg34649 is de opzet van het printen + opslaan gewijzigd.

Als we in de oude situatie een printje "Printen Kostensoorten" middels Control-F2 naar PDF zouden printen, dan:

1. werd het printje geprint naar C:\TROEP\PRFILE.PRN middels PCL5 koding
2. werd de C:\TROEP\PRFILE.PRN middels VeryPDF gekonverteerd naar C:\TROEP\PRFILE.PDF
3. o.b.v. de -view optie liet VeryPDF automatisch de aangemaakte C:\TROEP\PRFILE.PDF zien
4. o.b.v. de op het scherm getoonde C:\TROEP\PRFILE.DBF kon de gebruiker de keuze maken of ze de file wilde opslaan; het systeem bepaalde daarbij een defaultwaarde o.b.v. de opgenomen definities, en liet de gebruiker deze naam overschrijven.

Ook hier moeten we het emailen van het willekeurige printoverzicht in het achterhoofd houden...

Waar het op zich logisch is dat we eerst een file beoordelen alvorens we ervoor kiezen deze te willen opslaan (en pas dan een filename nodig hebben) hebben we de boel nu kompleet omgedraaid. Zouden we nl. in bovenstaand voorbeeld gebruik willen maken van de funktionaliteit "Bijsluiten bij Email" die Adobe Reader ons biedt (om de PDF die op het scherm staat naar iemand te kunnen emailen), dan zouden we altijd een document mailen die PRFILE.PDF heet. Voor de ontvanger van de email is dat uitermate lastig, immers zij kan de van U ontvangen bijlagen niet onder dezelfde naam opslaan, immers, ieder document heet steeds weer PRFILE.PDF. We hebben liever dat de print een naam krijgt op basis van wat wij voor die print gedefinieerd hebben, bijv. "Print ADPRKS d.d. 29-03-2010". Sterker nog, in 99% van de gevallen zullen we de print w.s. niet eens willen opslaan, maar willen we de print wel kunnen mailen middels een zelf opgegeven naam.

Nb: Voor Variabele Layouts geldt hetzelfde: Het is duidelijker de klant een PDF te mailen met als documentnaam "Faktuur 123456"  dan dat de klant iedere keer weer een Faktuur in PDF krijgt die PRFILE.PDF heet.

Willen we het document met de juiste naam kunnen mailen, dan zullen we éérst een bestandsnaam moeten opgeven en pas daarná de PDF moeten genereren. Ook die methode werkt niet helemaal fijn, immers, als we éérst om een bestandsnaam vragen en we nog niet eens weten of er een ASCII print (PRN), een HTML document of een PDF uit zal komen, dan kunnen we ook niet bepalen of er al een eerdere versie opgeslagen is, en dat het systeem de volgnummers moet toepassen. Vervolgens zouden we te maken krijgen met problematiek dat de file eigenlijk eerst al moet worden opgeslagen onder de betreffende bestandsnaam, om er vervolgens achter te komen dat we de file helemaal niet wilden opslaan (omdat als we de inhoud bekijken, we zien dat deze versie niet juist is en niet bewaard moet worden).

Al met al hebben we de volgende  nieuwe werkwijze bedacht. Onderstaand voorbeeld betreft een "Printen naar PDF" voorbeeld, maar i.p.v. een PDF kan dit net zo goed HTM zijn.

1.  de print wordt naar C:\TROEP\PRFILE.PRN geprint met PCL5 koding
2.  de print wordt met VeryPDF gekonverteerd naar C:\TROEP\PRFILE.PDF
3.  als VeryPDF in stap 2 konverteert, wordt de "-view" optie altijd uitgeschakeld; VeryPDF toont dus niet wat ze gekonverteerd heeft.
4.  de verkorte versie van "Opslaan Shift-/Control F2 Print" verschijnt. Hierin is de bestandsnaam al bepaald o.b.v. de vastgelegde definities. De gebruiker kan vervolgens deze bestandsnaam nog overschrijven. Het path staat zoals voorheen vast op hetgeen in de parameters is gedefinieerd. Tevens kan ze aangeven of ze de intentie heeft de print te willen opslaan J/N.
5.  de C:\TROEP\PRFILE.PDF wordt nog niet echt op het netwerk opgeslagen; wel wordt er (lokaal) een kopie gemaakt met dezelfde bestandsnaam als door de gebruiker opgegeven. Ofwel, zou de gebruiker ervoor kiezen de file op te slaan als "G:\VeryPDF\PDFPrints\PROFIT-DEMO\ADPRKS\Printfile ADPRKS 20100329 WR.PDF" dan zal ze worden gekopieerd naar "C:\TROEP\Printfile ADPRKS 20100329 WR.PDF". Op dat moment hebben we een nog niet opgeslagen versie, doch met dezelfde bestandsnaam als die we hebben opgegeven.
6.  file "C:\TROEP\Printen ADPRKS 20100329 WR.PDF" wordt vervolgens geopend alsof er vanuit de explorer gedubbelclicked werd op deze filename. Indien explorer zo staat ingesteld dat PDF documenten met Adobe Reader worden geopend, dan zal Adobe Reader worden gestart en wordt de PDF getoond; dit met de bestandsnaam zoals door U opgegeven. Adobe staat U nu toe de PDF onder deze naam te mailen.

7. indien we geen intentie hadden de printfile op te slaan, zijn we nu klaar. Ook al wilden we de print niet opslaan, we hebben wel een bestandsnaam kunnen opgeven waaronder we de print konden mailen. Hebben we echter wél aangegeven de intentie te hebben de printfile op te slaan, dan kunnen we de PDF die op het scherm staat beoordelen. Op de achtergrond verschijnt nu een melding waarmee gevraagd wordt of de we printfile daadwerkelijk willen opslaan met de mogelijke waarden "Ja" en "Nee". De bestandsnaam waaronder we de file opslaan hebben we in stap 4 al opgegeven.

Nb: Voorheen heette de het printje altijd PRFILE.PDF (of variant), en bij aanvang van een nieuw printje werd de vorige PRFILE.PDF verwijderd/overschreven. In de nieuwe opzet wordt de file lokaal eerst opgeslagen onder de opgegeven bestandsnaam (om deze vervolgens onder die naam te kunnen mailen).  Er is geen funktionaliteit die dit soort printjes vervolgens weer verwijderd (behoudens handmatig verwijderen via bijv. de Verkenner).

[Johan]

De nieuwe opzet ziet er goed uit voor wat betreft het toekennen van de bestandsnamen. Dikke prima wat dat betreft.

Waar "het kwartje" nog niet valt (maar dat zal m aan mij liggen) dat betreft het opslaan als kontakt. Ik heb nu dus een keuringsrapport met een nette naam in PDF (fia Ctrl F2) voor m'n neus. Nu had ik, mits goed begrepen, tot gistermiddag de mogelijkheid om die als contact weg te zetten.

Opname in Kontakt is dan ook alleen mogelijk indien het om een type Variabele Layout gaat welke "gemaild" kan worden; op dit moment: Inkooporders, Opdrachtbevestigingen en Fakturen.

en

Het per print vragen voor opname in de Kontakten was echter nimmer de bedoeling;

een keuringsrapport zou nu dus blijkbaar niet gemaild kunnen worden (vanuit profit). Ik snap echter niet waarom niet álle variabele layouts als contact opgeslagen zouden kunnen / mogen worden.

[Peter Stordiau]

Ik snap wel dat je dat niet snapt. Zeker gezien de vorige versie.

Wat wij hebben bedacht (maar eigenlijk zo meegekregen als idee van jou zelf) is dat waar je een dokument kan emailen (automatisch) je deze niet beschikbaar hebt als kopie. Kan je natuurlijk wel weer een papiertje proberen te printen (kan bij de Fakturen meen ik wel), maar je kan het ook "archiveren". Wel, dat opslaan is dan leuk, maar opslaan als Kontakt is nog leuker.
Nou voel je wel, willen wij dit zelf gestand doen, dan moet het betreffende dus eerst kunnen worden ge-emailed. Technisch gezien heeft dit ook te maken met het ophalen van de NAW gegevens enz. en waarvan we hebben bedacht dat dit voor de Variabele Layouts allemaal werkt, en voor de niet-Variabele Layouts niet. En dat klopt ook wel aardig.

Voor een misschien beter begrip kan je het ook andersom bekijken :
Een willekeurige print kan je emailen, maar niet automatisch. Opslaan kan je'm ook, en redelijk automatisch, ware het niet dat je zelf de initiële opdracht moet geven. Opslaan als Kontakt zou ook kunnen, maar dàn krijg je dus problemen met het "dossier", immers, de sleutel moet op juiste wijze bekend worden gemaakt, en dat kan je alleen maar zelf doen voor zo'n algemeen printje.
Omdat nu alle Variabele Layout prints precies andersom waren gemaakt als dat ik wilde (als mijn ontwerp wilde), werkte het dus precies niét dat bijvoorbeeld een uitgaande Faktuur als Kontakt kon worden opgeslagen. Jaaa, die je met de hand deed. Die wel. Maar hoezo die ? immers, dat doe je als nazending of zo, en waar je de oorspronkelijke Faktuur niet doet, doe je deze ineens wel ? Raar.
En zo geldt dus dat alles wat automatisch kan a. een adres c.q. Kontakt sleutel heeft en b. desgewenst als Kontakt kan worden opgenomen.

Het is dus de regel met het idee erachter waardoor het Keurigingsrapport nu niet meer werkt. En dit klopt dus precies, want niemand wil dat ding (automatisch) kunnen emailen, en wat nu ook (nog) niet kàn omdat de gegevens daarvoor ontbreken. Emailen kan je'm dus heus wel (tenminste, dat hoop ik toch, handmatig), maar automatisch opslaan als Kontakt niet.