7 replies to this topic

[mikelandl]

I'm wondering how everyone handles printing forms (i.e. sales orders, invoices, etc.).
Currently we use a forms designer program to design the actual form. We then print the form and create a macro (.mac) file which gets loaded onto the printer. When an actual print job is sent to the printer, our reports have some PCL code to tell the printer to overlay the report with macro XYZ. It works but is a bit tedious. If the printer loses power it loses the macros (unless the printer has a harddrive) and they have to be reloaded.
We are looking to switch to a new method which would ideally not involve our customers having to load files onto their printers.
Your input would be appreciated.
Thanks.

[Ross Bevin]

Hi Mike,
I highly recommend you look at the ProIV PDF SSO (server side object). It has to be the coolest new product to come out of Northgate for a long time. Basically you build your PDF document purely from ProIV logic. Each page is like a canvas that you apply your text, graphics, lines, boxes, etc to. In your code you just keep track of the last print position you applied data to then execute a command to start a new page. You can also open existing documents and apply text and graphics to it. This comes in handy with say invoices. We produce a master copy then reopen and apply different text to designate F I L E C O P Y, etc. This tool is so much easier to produce PDF documents than the conventional XML/XSL route. If you need to add a piece of new text you just add a logic command to do so, no changing the XSL style sheet or XML output. See my earlier posts for more details.
RegardsRoss
PS: No, I am not being paid by Northgate :-)

[mikelandl]

Hi Mike,
I highly recommend you look at the ProIV PDF SSO (server side object). It has to be the coolest new product to come out of Northgate for a long time. Basically you build your PDF document purely from ProIV logic. Each page is like a canvas that you apply your text, graphics, lines, boxes, etc to. In your code you just keep track of the last print position you applied data to then execute a command to start a new page. You can also open existing documents and apply text and graphics to it. This comes in handy with say invoices. We produce a master copy then reopen and apply different text to designate F I L E C O P Y, etc. This tool is so much easier to produce PDF documents than the conventional XML/XSL route. If you need to add a piece of new text you just add a logic command to do so, no changing the XSL style sheet or XML output. See my earlier posts for more details.
RegardsRoss
PS: No, I am not being paid by Northgate :-)

Hi Ross, thanks for the input. We've considered looking into that. I've done a bit of Java programming with iText and have thought about writing my own SSO to do what you're using. It sounds like you've had some experience with XSLT files and XML. If the PDF SSO didn't exist would you recommend going that route? Were you using a graphical designer for the XSLT or were you coding it by hand?

[DARREN]

We use XML and XSLT here at TowerHill without issue. Outputting as XML gives us the flexibility to send the source data to any consumer as required e.g. we can send it to the API if being called from a Task, or create a PDF, word doc or spreadsheet as needed.

[Ross Bevin]

Hi Mike,

We were 2 days from sending a cheque to Antenna House to buy their XSL Report Designer/Formatter solution; price USD $10,000+ including annual support and licensing for 2 servers. I did a lot of researching and it was the best solution I could find where I could get up and running as fast as possible. I had spent a month learning to work with the XML output generated by ProIV and designing the XSL style sheets (1 month free trial). It was a good solution but it took time to develop in. The thing I liked most about their designer tool was that it was WYSIWYG and used an example .XML file as the design template.

Fortunately though I participated in the Northgate webinar that day in January that show cased their PDF SSO solution. I, like many seasoned ProIV developers, want to use tools that are as rapid to develop in as ProIV is. I will challenge anyone and say that the PDF SSO is the fastest way to develop PDF documents such as Invoices, Purchase Orders, etc. I just finished a project to produce our invoices as PDF documents using this SSO. We had a users group that continually vetted my layout and would provide feedback for changes. E.g. move a message from the header to the footer, position the French invoice watermark higher up than the English, make the font size smaller for French field names in the header because they were generally longer than their English counterparts. The interesting part was our invoice detail lines. We are a manufacturing company that sells polystyrene products with many that have dimensional pieces. I needed to print and position this dimension data at different places on the line depending on the item type. I can not imagine the time that this would take if I used a different solution.

The ProIV PDF SSO is a one stop shop whereas the XSL/XML method is not. If I have to position, print text/not to print text, resize, change colour or do anything that is dependent on a some code or type I simple do so in logic; I don't have to change both a style sheet and the XML output function. Here's a simple example:

IF OP_HDR_INV_LANGUAGE = 'F' THEN
PdfSSO.setFontSize(font6)
PdfSSO.setFontStyle(bold)
#X = 60 #Y = 550 $TEXT = "Date de la facture:"
ELSE
PdfSSO.setFontSize(font8)
PdfSSO.setFontStyle(normal)
#X = 60 #Y = 550 $TEXT = "Invoice Date:"
ENDIF
PdfSSO.placeText(text)

• I can make the above change to my solution in 2 minutes and I'm done.
• I have the full power of using ProIV logic to set business rules in logic to change any aspect of what I want to paint on a PDF document.
• I don't have to maintain multiple style sheets for different language layouts.
• Any ProIV developer in our organization can maintain my code and build functions that create PDF documents; they do not have to be a style sheet/XML expert.

I know some style sheet solutions allow you to make decisions based on a data type, etc, but absolutely nothing can touch the ProIV PDF SSO for rapid development, flexibility, maintenance and simplicity.

Regards
Ross

[Ross Bevin]

Hi Darren,

How's it going?

Yes, with the XSL/XML solution you do have the ability to be able to send the XML output to say a customer or vendor. But of course you can't simply change your invoice report function over to output to XML because it ignores header information (why this wasn't included is beyond me). Yes the XML may be handy to have but no one outside our organization has ever requested it. We use EDI with all of our major customers and I don't see that changing any time soon. Everyone has different needs but my recommendation to anyone who doesn't have the requirement to produce both a PDF document and XML output would be to go with the PDF SSO. If you think you may need to produce XML in the future then create one report function to do so. In that function also include the PDF SSO code in logic to produce the PDF. That way both outputs benefit from using the same business rules to produce both.

Regards
Ross

[Matthews Estrice]

Hi Mike,

Please find the attachments which tell the story of how we do printing at ProInvest Software for our PROIV application.The files names will also indicate to you the purpose of each screen shot.
We take 3 steps then we deploy a report.We have over 450 of such reports on our ERP.One report can print about 4 different printing modes using a single java servlet.

We still prefer printing from PROIV legacy report system,it is faster than renderring the reports on the 3rd party software for batch runs.

The PDF reports have signatures,CRUD(Change,Replace,Update and Delete) modes on edit boxes.Repots support Lexicon.Unlimited level of control-breaks.We can print on memory or hard drive.Reports are Web service enabled.

You can visit our website also ie. www.proinvestors.co.za / www.proinvestors.co.uk gallery tab.We have further information on Twitter - @proinvestorscoy please join.

Matthews Estrice

[mikelandl]

Sorry for my late reply, was out of the office last week.
Thanks everyone for your valuable input. Depending on the pricing structure and output we may investigate the PDF SSO option. Originally we were considering the XML + XSLT solution but if it costs $10,000 for a decent XSLT gui editor that might be an issue.