Do you mean embed extra fields into the PDF, superimposed over the PDF content? Or do you mean linking the document to various IFS data elements?

If the former, I am not sure how that would work. Any sort of automated routine that manipulated the PDF every time it was printed would mean the fields would get added and re-added every time.

If the latter, a document can be linked to pretty much any LU in IFS, depending on how you want to link it.

Finally, I am not sure how an automated process could reliably stamp additional data onto the PDF unless you inserted a cover page onto the front of the PDF with indexed fields. Otherwise the automatically added fields might be getting placed on or over existing content, marring it (or the index fields themselves).

Can you elaborate on the business process you are trying to accomplish? My first instinct tells me that the PDFs should have a cover page added to them before being stored to IFS, meaning that perhaps this isn’t really an IFS issue? PDF manipulation software comes in lots of shapes and sizes, and adding a page to the front of a PDF is a somewhat typical operation (PDFTk can do that, for example). PDFTk Pro, can actually add pages with watermarks, so depending on how the watermarks can be configured, a watermark could be used to insert your index fields.

Thanks,

Joe Kaufman

PS. You can also use PDF automation to add properties/keywords to a PDF in the document’s metadata:

https://acrobatusers.com/tutorials/print/auto_insert_metadata/

Such data can then be plucked out later, though probably not nearly as visibly as stamping elements directly onto the PDF.

@sutekh137 ,

The scenario is this:

1. We receive drawing(pdf) from a customer for a part we are going to make.
2. We store it in docman with a connection to the part no.
3. We print out both work instructions and the pdf for production.
4. Often we print out multiple work instruction at ones and the drawings afterwards. Sometimes several users at the same time. It all get mixed up.

The challenge is that there is no indication of which drawing belongs to which work instruction (basically the cover page for the drawing).

If we could have the info printed on the drawing, there would be no doubt.

Hans,

Thanks for the further explanation.

I don’t think you are going to get around this by doing anything other than attaching a title page to the front of the PDFs before storing them. Most of the issues I initially mentioned still stand. If you stamp the Part No on the document every time it prints, it is going to get stamped over and over. If you try to place part no over a spot on the document that is the same color as the font, folks won’t be able to see the stamp. Etc.

It would be pretty nifty if IFS had a print option that put a title page on front listing the LU the document was attached to and the index fields linking it, but I don’t think IFS has that. 

Do you have the option to print the PDFs from outside IFS (like a .NET program)? You could access the EDM_FILE_STORAGE view directly and grab the BLOB field representing the file. Then, you could programmatically generate a PDF page and insert it on the front of the document. But that means all printing of documents would have to be done by some external program (could be called with a RMB custom menu, though, meaning it would be fairly tightly integrated to IFS).

Thanks,

Joe Kaufman

@sutekh137 ,

Printing a cover page will not solve the main problem. Which part no does the printed drawing belongs to? - The cover page would just be another piece of paper in the printer tray. However, I am considering doing something similar for solving a related problem.

We do have external programs (written in .net) that calls IFS. We tried to get rid of them when we upgrade to apps10. Now, they are sneaking back in. It could be a solution.

Hans,

I guess I am still not quite understanding the issue. Must be that one document might be linked to several part numbers, so you want to know what part number it was printed from in each scenario?

If that is the case, then yes, attaching a cover page to a document won’t help. But attaching a cover page to the document upon each printing of it sounds like it would help. Being forced to bring back a .NET application is not ideal, I agree, but I don’t see any way around this short of taking over the printing process and manipulating the PDF on the fly. I have not run across anything in Apps10 that would solve this business issue for you natively.

Thanks,

Joe Kaufman