Skip to main content

Hi all,

We’re on Cloud 23R2.

A question around the logical printers that aren’t connected to a physical printer.

In Apps9 we have a logical printer - PDFEMAILER which isn’t connected to a physical printer. When the users print specific order reports to this printer, a custom event will pick it up and email the pdf to the external parties. This has been working fine.

 

Now when I try to do the same in Cloud (an upgraded system from apps9), the print jobs go to Remote Working when I print to PDFEMAILER logical printer. If I print to a logical printer that has a connected network printer, it comes out fine and the job goes to state - Complete. 

 

Printing to the standard no _printout printer too works fine where the job gets completed and the pdf gets archived.

 

Things I’ve tried:

  1. Reinstall, restart PA, restart utility server (the server with PA installed)
  2. Create a new logical printer (without a connected physical printer)
  3. Restart reporting pods on mws

 

Any ideas why? Is it because the mws or PA doesn’t know what to do with the logical printer?

TIA.

 

2 questions:

  1. Is the PDFEMAILER logical printer assigned to one of your Report Print Task Templates inside IFS?   I suspect it is but worth checking.
  2. Is the PDFEMAILER included in the ifs-printagent-config.xml file on the mws?  I suspect this is perhaps your problem.  Even if it is not printing to a physical printer you still need an entry in this file, like the PDF_PRINTER does.  The mapping for each logical printer in the file should be something like this:

 
    <PRINTER_MAPPING>
      <LOGICAL>PDF_PRINTER</LOGICAL>
      <PHYSICAL>DUMMY</PHYSICAL>
    </PRINTER_MAPPING>

 

HTH,

Nick

Hi Nick,

  1. Yes, it is included.
    1. I forgot to mention in the earlier post, but yes have verified there is an entry in the xml. However, I’ve tried with a physical printer like DUMMY which stopped the job in error. Currently it is blank as highlighted below. Should there be some entry like a dummy printer?

       

Essentially, what I want is the PDFEMAILER to do nothing but archive the report - just like the NO_PRINTOUT does. The difference being, when the users pick PDFEMAILER, the system knows the associated pdf must be emailed out, whereas with NO_PRINTOUT, it merely keeps the file in the archive.

Thanks.

What is the error you get when you map the logical printer to the DUMMY physical in the config file?

Also, you may need to set up a fake physical printer (really, a local print queue on the server) so it actually can be seen as a “printer” on the server, which is then just used in the PHYSICAL mapping in the file as noted before.

For example, we have a local printer defined on our server which provides a local print queue on that server which doesn’t do anything, and that is what the logical is mapped to in the config file.

I’m sure this is what your issue is… you need something mapped in the file.

What is the error you get when you map the logical printer to the DUMMY physical in the config file?

Please see below. Should we setup a dummy printer in windows (not sure how yet) so it has something to print to?

 

Yes, see my last note above.  

Yes, see my last note above.  

Yes mate, sorry I jumped the gun! 😁

I set up a fake generic MS printer on the utility server and that did the trick! Many thanks!

Out of curiosity, why did you have to go down the path of setting up a fake physical printer? Is it because you would have otherwise gotten “Remote Working” jobs with logical printers that aren’t linked to a physical printer just like in my case?

If that’s the case, seems like IFS should have the documentation updated to indicate that all logical printers must have a physical printer linked - unless it is the no _printout printer.

By the way, if you remove the PHYSICAL tag altogether from the xml, you don’t need a fake physical printer mapped. The system will treat the logical printer as a no_printout printer.

Reply


Terms & ConditionsCookie settings