Print Part Attachments When Mass Printing Job Travelers

We’re on 905.701. We currently use Mass Print to print a number of Job Travelers at once. For each Traveler, we then manually print an Engineering Drawing (Part table attachment) for each manufactured part that is in the job BOM. We waste a lot of time printing the Engineering Drawings manually and want to automatically print them with each Job Traveler.

From researching on here, it looks like the potential solutions are:
-Crystal Report with OLE object tied to folder with all of our Engineering Drawings
-APM/APM+ (we currently don’t have either implemented, but are planning on doing so at some point)
-3rd Party Software (Rob Bucek said he uses PlanetPress Watch)

Does anyone have experience resolving this issue with either one of the above potential solutions or anything else? Suggestions?

Tyler Leonard

1 Like

My company is interested in doing this as well; we’re in exactly the same situation, but with version 702A.

We’re thinking of using APM (I think Plus is required, but I’ll have to check on it) to pick up the part number and attach the drawing to it. Additionally, I think this can separate each traveler as a separate print job, so that they can be stapled and/or stacked separately with the drawing.

APM+ is definitely a working solution. You would have to do some Work to get the drawings into Doclink repository and then you can use the Supplemental Documents function.

Using the OLE objects as I remember it will not work very well except in a limited fashion.

I was the person responsible for the initial vantage and e9 integration with doclink and crystal as well as ssrs.

The primary issue is being able to have a programming process to access those drawings and route them to the printer – doclink has that functional framework with the repository setup which requires APM+.

There are definitely other options – After I Left Epicor I worked at an Epicor Customer here in Houston area- this company merged into a 2.7 billion $ company .

One of the tasks we had in the IT group was to find a global solution for all locations for Document management including the Supplemental Documents type of concept which I was familiar…

The IT Manager in charge of this project had me come into a meeting with the Copier Service organization that sold and serviced all our Printer/Copy machines in our region – I think at the time most of the copy machines were RICOH at least the new ones being purchased.

This group demoed to the IT group the ability to do many of the Functions that doclink can do such as supplemental documents. I cannot remember the affiliation between the software developers and the copy machine manufactures or developers – meaning I don’t know if RICOH or the Distributor owned this product or just resold it . At the moment I do not remember the name of the product as it was 5 years ago but it is possible that if you have these big Full Featured copy / Print Machines in house and have Distributor or Service organization that works with you on these Machines – they may have knowledge of such software. I left Forum before this was ever implemented but I did get a demonstration that convinced me that moving forward would have provided what we needed.


Kevin P Rosell

Cell: (281) 615-5248

For info Dot Net have a Job Traveller Attachments print utility, it’s an Epicor embedded solution so no need for separate software etc.

We are also on 9.05.701 and we use a C# customization to print the drawings. This is not exactly automatic in that the user must click a button we added to the Job Traveler report screen. The c# code gets all the attachments (identified by a specific DocType) for the jobs in the filter and sends it to the default printer of the user’s system.


CodaBears has a Job Packet Print Utility that looks like it will print the attachments with the Travelers. It looks like it can select the jobs marked for Mass Print. No, I don’t work for CodaBears. :slight_smile: We are having them do some work for us and I happened to see it on their website:
We don’t currently use the utility, but it looks like a useful tool.
We earlier looked into using APM/APM+ to do this, but we didn’t want to have to copy all of the part attachments to the APM repository. The newer versions of APM+ might be able to print external documents that aren’t in the APM repository.

Thanks for all the info y’all, very helpful.

C# Customization - My coworker and I do some coding here, but don’t have coding backgrounds (ie. we’re not very good at it). Bitman, or anyone else with experience, is doing this via custom code pretty involved or would it be possible for mediocre coders?

Crystal Report - May be a good band-aid solution. Our drawings are auto-exported out of SolidWorks as PDFs into a folder, then DMTd into Epicor daily. PDFs don’t work well as OLE Objects. I’m guessing we could auto-export as PNGs as well and insert these as OLE Objects. Are there issues/concerns beyond this? What does “Using the OLE objects…will not work very well except in a limited fashion mean”?

3rd Party Application - Seems like there are a few companies that do this. Would be a bit wasteful though if you’re planning on eventually doing APM/APM+. How have experiences been with CodaBears, Dot Net, and any of the other companies that provide this solution whether you used them for this solution or something else?

APM/APM+ - Will try and research whether newer versions can print external documents that aren’t in the APM repository. That seems like a function that could be useful here and beyond this application.

Copy/Print Machines - Don’t think we have a machine or a service organization like that, but that’s an interesting idea.

If you think you have enough coding skills to take our existing code and adapt it to fit your environment, I can share it with you. Just as you, we export our Solidworks drawings to pdf, but from what I understand you then import the pdf in your database. That is the part you would have to change because we only store file path (DocType = attachment link) in Epicor. Our code retrieves the path to the pdf file from the part revision attachment table and prints the file from the shared folder.

Yea could you upload the code on this thread? I don’t know if we’ll be able to adapt it, but sure as hell would be easier than starting from scratch.

This is something we have struggled with for quite a long time. Would love
to see your code as well Bitman.


Norman Hutchins
Systems Administrator
Howell Laboratories, Inc.

Ok for those interested, here’s how it works:
(As english is not my native language, sorry if I make mistakes. I will try to describe the solution clearly.) Feel free to ask clarification if needed.

We use the Autovue program to print the files. We can pass command lines arguments to have it read a text file which contains the paths of files we want to print.
We use UD fields in the company table (shortchar04 and 05) to define the autovue executable path and the text file location on the workstation.
We added a customization to the job traveler screen, added a button in the report options section and add the code to this customization. The user selects the jobs in the filter, prints the job traveler and click the button to print the drawings. Job travelers and drawings will need to be matched after printing is done.

The code connects to the JobEntry BO to retrieve the attachments links from the JobAsmblAttch table, based on the DocType we want. We store this information in a temp table so we can filter out the duplicates (we don’t want to print a drawing more than once), and then we generates the text file on the workstation, one path per line. Finallly, we send a command to have autovue read the file and print each path stored in it.

Probably not the best solution, but this is working well for us, hope it can help some of you. Find the code attached.

print_Job_attachments.cs (7.9 KB)

Thanks Bitman. Looks pretty involved, so we’re going to start by trying a Crystal Report with OLE Objects. Will let the group know if that works out.

Dot Net has a Job Traveler Solution that worked great for us in Epicor 9.05.702. They uplifted it to 10.1.500, but we have not installed it fully yet. I believe they merged with Epicor now. I found this link out there

Hi Bitman,

My name is Alex and I would like to thank you for sharing information on this challenge as I found it very useful in my case. However, as I am very new to Epicor system and a very Junior in programming, not everything is obvious to me. Is it possible to communicate with you and clarify a couple of moments?

Or if you could just explain what are those values or rather where are they coming from (“ENGRLINK”, “DRAWLINK”, “INSTR”) you are checking for in the follow part of code that would be wonderful as well.

“if(asar[“DocTypeID”].ToString() == “ENGRLINK” || asar[“DocTypeID”].ToString() == “DRAWLINK” || asar[“DocTypeID”].ToString() == “INSTR”)”

Any help would be much appreciated!

You can contact me here:
Time Zone is EST.

Thank you,


Please keep the communication on the site for the benefit of everyone.

Hi Jose,

I ma not trying to hide anything or be selfish I just need to ask the person couple clarification questions, that’s it and also I have modified my reply.

I am new to the community so will learn a long the way.



Those are document types as setup in the Document Type Maintenance

Hi Alex,

Like Jose said, these are Document types we have defined in the DocType table. ENGRLINK stands for Engineering Link, DRAWLINK is for our technical drawings, you get the idea…

If you have any more question, feel free to post it, I will be glad to help if I can.


Hey guys,

I have tried some stuff for the last couple days but couldn’t get anything sufficient. The thing is we do not have any Document Types set up as well as not using any third party apps to print Jobs in Job Traveler.

However, I traced some logs when printed a preview and found next:

      <PartDescription>1224 headstock machining</PartDescription>
      **And a bunch of XYZ info from JobHead Table printed.........**

Here I found some interesting stuff:

      <DrawDesc>M0161 headstock.dft</DrawDesc>
      <FileName>N:\Drawing Files\12in mini\M0161 headstock.dft</FileName>

JobHeadAttch table is not in DB and I assume it’s a temp table that is created while a printing preview process is in action (I might be wrong here though).

Do you know guys if there is a way to set up a scenario like:

  1. Place a custom button on a JobTravaler screen.
  2. When the button is clicked just grab that path and send it to print to a whatever network printer is set up?

If you guys could give a hint or a pointer where to look at that would be awesome and appreciated a lot!



Hi Alex,

This is almost exactly what the code I posted does. As we don’t want to print every attachment that may be present in the job, we use the document type only as a filter. So its not mandatory to make this work and these checks could be removed from the code.

For direct printing, there is probably a way to do this, maybe others more knowledgeable than me in programming could help you find a way to do that.