Good morning,
We have dedicated cloud tenancy. We do not have Docstar, but we do have the Documents module. I am interested in attaching files to my partlot table. The files are material certifications in the form of PDF documents. The filenames match the lot number in epicor.
I want to make sure I understand how the files are stored.
When I attach a file, the source is our network folder. As I understand it, Epicor saves the filename and path, then tries to access it when needed. Instead of storing the entire file in the Epicor cloud, all of our certification documents will only be stored on our network.
I am looking at various forms in Epicor classic. Namely, Document Type Maintenance, and File Attach Maintenance.
In the event that our server gets an upgrade, our linked file locations might change. For example, if our current network folder for certifications is \Myserver1\certs. Then we upgrade, and our new folder location is \Myserver2\certs. I would like to find a place in Epicor where I can enter the network folder, and update it anytime the folder changes, to keep our files linked correctly.
I see the Base URL field in Document Type Maintenance. I also see the Current and Target Base paths in File Attachment Maintenance. My question is, how exactly do I set these fields up to work the way I expect them to?
Eventually, I am looking into making a BPM to link potentially thousands of cert documents to their related partlot entries. Anyone have any advice for or against this?
Thanks!
Nate
Attachment Type Maint. is your first step. That’s where you set up your base server URI. Items attached to Epicor will be added to subfolders within that location. We use “File Transfer Using Service” so Epicor will copy the file using the EpicorAdmin account. We’re on prem, so that simplifies things greatly on our end. Client Direct Copy might be better for what you’re doing.
When you attach a doc from the Epicor UI (drag and drop) it will create, within your root URI, a folder corresponding to your company, and then a subfolder related to the Epicor table that is parent to your file. So if your URI is //fileserver/epicorData, a customer PO doc on a sales order might end up in //fileserver/epicorData/YourCompany/OrderHed. Note that’s where it auto-places files that you drop into the UI. You can also link it to files elsewhere…which has been a bane of our existence and was a major reason to move to DocStar, which has been a process unto itself.
The system records this location in the ice.XFileRef table. This is then linked to the Epicor business object via ice.XFileAttch. These values are pretty much static once you’ve uploaded a doc. We’ve maintained our fileserver name whenever we changed our storage, so I can’t directly speak to updates. I’d assume changing the file server name would likely require a DMT update against XFileRef so the system points to the new location.
From my testing, I first setup a Document type call “certs”. I added the network folder location here. Now when I am in Lot Entry, If I attach a document of type “certs” then I automatically get a dialog box allowing me to choose a file from the network folder I added previously.
I tested the File Attachment Maintenance, and pulled up the document type I just created. I changed the target base path, and it seem to do just what I needed! No need for DMT, or (thankfully) docstar!
I’ll post back here once I have an automated approach for linking existing files to existing partlots.
You know, I’ve actually been looking for something like this. A lot of my users want to see things at a higher level than where they’re attaching things. Like, we’re attaching photos of outbound shipments (in case they get damaged by shipper) to outbound shipments, but users want to look up the PO and see everything relevant to that object without drilling down. It’s not a huge deal, but it’s been in the back of my mind for a while.
@jtownsend That was what I did on the inbound side. I made a ubaq to attach invoices to all part lots and the PO for a receipt by calling the function multiple times.