We’re in the process of migrating a bunch of historical documents to Epicor and storing them via the SharePoint integration. Everything makes sense, and the metadata feature is really cool!
The one stumbling block I’ve encountered is around ContentTypes. Epicor automatically creates new SharePoint ContentTypes for every Document Type (Epicor) that is associated with the SharePoint attachment types. It then automatically creates content type fields in SharePoint for every metadata field that’s created. However, unless I’m missing something, it doesn’t appear to create uploaded files as said Content Type, making filtering the library more difficult.
Anyone have any experience with this? I was hoping to set up views in the SharePoint library for easy viewing of all “Item Datasheets” or “Shipping Doc”. I’ve thought of creating a dummy “Document Type” metadata column, mapping to some random DB field, then overwriting it with a BPM during document upload, but was hoping for a more convenient approach.
Alright, so this project is utilizing a custom upload script I wrote that scans a directory, uploads the files and attaches them to the associated “thing” in Epicor (Customer, Part, etc). I’m using the REST API to accomplish this and am manually collecting the necessary metadata and sending it along to the Ice.BO.AttachmentSvc/SpUploadFile method.
It turns out that when you attach a file using the actual Epicor client, it is also setting the “Category” and “Author” columns (in addition to any other configured metadata). The Category column is set to the Document Type from Epicor, and this works as a Content Type replacement for my purposes.
So… if you’re uploading files using the REST API, make sure you path along _Category and _Author in your metadata object on the SpUploadFile method. Note the use of Sharepoint’s internal column name and not the display name.
You’re not missing anything Forrest. A bit of history:
The original attachment framework was first developed on File Shares. It has a specific folder structure which you have seen (Company/Table/files…) When SharePoint was added, everything goes into a single Document Library with the same folder structure. This holds true for DocStar too but SharePoint and DocStar don’t really use folders. They only provide them for humans who are used to the concept. As you’ve noted, the power is in the metadata. Treating ECMs like file folders takes away some of the benefits of an ECM. In the case of SharePoint, there is also a limit on how many files you can have in a single folder / document library. The classic document library had a 5K limit in a folder, while a modern Document Library can hold 20K+. The more you put in, the worse performance can get. As you’ve noticed, you also don’t get the full goodness of SharePoint content types since there is only one library.
I was working on just using the raw link type and creating a web hook in SharePoint to link the document to Epicor in the background. You need columns for table, company, key items (SOnum, PONum, etc.) in your document libraries to do it. That’s right, libraries. Now I’m not restricted to a single Document Library and I can pick and choose my metadata, sensitivity labels, security, retention, etc. I’m back at a company where I have more access to M365 and hope to pick that up again later this year after our upgrade to Kinetic.
I just opened a support case on this topic yesterday. I don’t understand why Epicor is bothering to create the site/library Content Types if they aren’t going to use them. I understand the folder structure being based on historical file-share structure and I’m fine with that, but let’s use the Content Types too. (Side note, folders in SharePoint can actually be very useful beyond just visual organization!) Also - there are functionality differences between uploading an attachment from a Kinetic form compared to a Classic/Modern form, at least in 2021.2.15. Two examples that occur when attaching in a Kinetic Sales Order form:
Epicor throws a warning that the file already exist even when it does not
The ‘Status’ field does not get set properly (choosing ‘Final’ ends up as ‘Not Final’ when posted)
I will be testing this in 2022.1 next week and will check back with results and any updates from support. I know we will probably end up with ECM, but trying to get some basic functionality with the built-in stuff.
My case has been updated to say that the content type and Kinetic form issues are slated to be fixed in 2023.1 - updates will be in PRB0255112 and PRB025350 respectively.
