I have been asked to check if there will be an issue with us as a company storing lots of documents in Epicor. We are looking at keeping PDF / excel forms against customer records in Epicor going forward.
Can you answer the following please?
What will be the impact of this on the application?
Will we have to keep increasing the size of the instance it sits on?
Is there any way we can automate that certain forms are checked for specific retention timeframes and be removed after 6/12 months for example?
Thanks
aidacra
(Nathan your friendly neighborhood Support Engineer)
2
How would you like to store these attachments? The attachments themselves are not stored within the Epicor database itself, so there are a few options depending on your version of Epicor:
Within a file system share in your environment
Within a Sharepoint instance
A Cloud storage provider (DocStar/Sharepoint Online)
The answers to your questions are different based on the choice of storage provider.
Like all Epicor functions… there is set-up required,
DOCUMENT Types get defined (which is slick cause u can secure TYPES per defined user access or user groups)
Security per type (can then be defined)
Subsequently, someone would 'store a document “somewhere” in the server/folder environment…
proper security to store the doc per folder and access thru epicor should be synced-up!
When the Doc-attach is applied within Epicor, only the ‘path’ or link to the document is entered.
Therefore… as long as configuration/security is correct, the document can be stored almost anywhere.
Of course, the folder where the document got saved… would be a folder the user has access to in order to save the doc there, or whoever actually saves the file… if there is extensive document control where a-person manages the hands-on.
As long as the software to view the doc is loaded on the PC where a user is … a user can open it thru Epicor via doc-attach. Depending on ‘what the file is’, normally there is no delay/impact. I have been on shop-floor, at a machine… and cad drawings/other elaborate data-files (quite extensive) have loaded/appeared rather swiftly.
IMPACT - fairly minimal if the Epi-environment is not already constrained
increase size - whatever is stored as files in folders on the server location… the space utilized will grow based on continued doc-attachment
Retention and removeal…
Presume you save doc and perform doc-attach… it’s just a link
You later delete the actual file… 8 mths later
IF… someone in EPICOR clicks on the remnant link, presume FILE NOT FOUND will result!
I presume, that if you are going to cleanse files based on ‘some business rule and timing’…
the partitioning of the storage folders by name might help you. ie: Sales and Quote stuff retained for 6 mths; Job stuff 8 mths; Finance 12; etc. Separate folders would enable a fairly quick WIPE
With storage… fairly cheap, why is there a need to WIPE?
To fork this conversation a little (not much)… I have had a situation where I had to migrate from one server to another and ensuring all links were properly pointing to new locations was pretty horrific involving manipulating SQL tables with no user-friendly info. @aidacra, are you aware of any improvements in maintaining this structure of links and file associations?
aidacra
(Nathan your friendly neighborhood Support Engineer)
6
As of 10.1.400.x there is a module to maintain the links to attachments via Attachment Path Maintenance.
We are currently running on-premise Epicor 10.2.500.7. I noticed in your previous above reply post, you stated that Epicor will work with the following repositories:
Within a file system share in your environment - This is what we are using
Within a Sharepoint instance
A Cloud storage provider (DocStar/Sharepoint Online)
Is online (off-premise) SharePoint instance as repository compatible with Epicor 10.2.500.7? If so, are there any known bugs or performance issues?
