We are in the process of implementation. We were sold on the idea of Epicor ECM (Docstar) to store our relevant customer data alongside the associated quote, order, customer, vendor, etc… However now that we are trying to work out our processes around kinetic and ECM we have run into a few issues. We are a Graphic Design business and therefor to work with larger files frequently. During testing we started to hit limitations in the size of files that could be attached in Epicor ECM. We also attempt to use the Sharepoint attachment type to see if it had limits or not. We have found both options seem to max out around 175 MB. Epicor might spin for a while but will eventually error out due to file size.
Many of our files are below this threshold, but it will be awkward to have multiple storage locations and processes based on file size.
Is anyone else experiencing issues attempting to attach files greater than 175 MB?
I would open a call with Epicor about this. It seems I can’t upload more 100MB file directly on ECM website. But if I use the client that’s not an issue.
Nice find Jose.
I’m not sure what ECM uses, but the File Transfer Service I think has a recommended max of 150 MB. There is no chunking.
I have thought about making a function to get around this limitation, but we have yet to need it.
Jose,
Thanks so much for prompt response. We already did the Epicor ticket dance, it went nowhere. They were asking development but the ticket lingered on for too long. I figured I would ask others here to see their experience.
You mention it worked for you in “the client”, do you mean the Smart Client? We attempted that also but had the same limitation. We are a cloud customer, not sure if you are on prem or in the cloud.
I believe @klincecum is correct that it is an HTTP file transfer limitation. I think it is related to this c# - How to increase the max upload file size in ASP.NET? - Stack Overflow
One of the presenters at Insights was showing how to use the DevTools to do trace logging and mentioned that the Smart Client was more or less a web browser, which could mean it would have similar limitations on upload. I could be wrong, maybe our test had other issues.
Thanks for your help so far. If anyone has any other thoughts keep them coming.
no I mean the ECM Client
Maybe an option is to use the File Link Document Type and upload the document outside of Kinetic and then add the attachment using the URL.
I still want to see what Epicor says, I’d play support roulette again and see if they can get some traction this time.
That being said, if they are looking for workarounds, I’m betting we could figure out something.
Tried it in classic client with a 200MB file and it didn’t appreciate it much.
But after much waiting the record made it to DocStar just fine
Meta Data, Rendering and all
Agree with @Mark_Wonsil, for large files unless you absolutely NEED this in the on the docstar server, IMHO a link would be better. That said you could always zip into smaller chunks and updload the pieces… Not the best solution, otherwise I believe you would need base System IO file access to upload a file that large or another API that supports chunking like @klincecum referred to.
I suspect (since it worked for me) that the limitation is in how they setup your max upload size in the SaaS web config for you. Not a limitation of Epicor itself or DocStar just the AppServer (IIS) setup
You did that through the browser WOW! 
No I didn’t try through the web browser, just classic client… I’ll try the web browser next I guess… Wish me luck
Might as well get used to it. 
I’m fine with browser it allows a tailored UX without the need for business/system logic which SHOULD all be on the server 
Design transition is awesome IMO just the UX needs work still, but from what I am seeing is VASTLY better from initial Kinetic design in 10.2.500 ish I think…
I agree it’s most likely the application server. People upload large files to DropBox, OneDrive, G-Drive, etc. using a browser every day.
For those of you mentioning the File Link type, I agree it can assist us through the large file conundrum but lacks the panash of Metadata 
Yes I want my cake (large files) and eat it too (Metadata).
We have also trialed Sharepoint connection type, but as @josecgomez points out I am fairly sure this is a SaaS web sonfig limitation, also an HTTP limitation. Third party sites like G-Drive, DropBox, use techniques to chop up the files in byte (not actually 1 byte, but a pun) sized pieces and reassemble them at the server side to overcome the limitations of HTTP. Remember the not so old days of FTP which was purpose built for transfer of larger files.
All good stuff and grateful for the thoughtful and PROMPT responses
Many files can hold their own metadata as well (many images have XMP metadata), and you should be able to edit the metadata for linked files in DocStar/ECM once the link is in there.
Au contraire. I would argue that the metadata story is stronger with links. In Kinetic, at least the last time I looked, you could only automatically add meta data from the table that you’re attaching to (so no customer name or ID for quotes or order for example). Again, the last time I checked in SharePoint attachments, all of the documents go into one Document Library. This means all documents share the same meta data. 
If you create Document Types in ECM or SharePoint and use links, you can have many Document Types with only the meta data required for those document types. You can have multiple SP libraries with their own security and retention policies. ECM has very strong meta data, security, and retention capabilities and is integrated with Kinetic very tightly.
To my knowledge, Kinetic doesn’t store any meta data. It only prompts for it during the upload and lets the repository store it. If you capture it during the browser upload too, then what’s the difference? 