It has been a while since I have reviewed the meta data functionality in Kinetic, but I am slightly confused by the premise of it.
Say I create a document type called QuoteAttach and I want to have the customer ID as a piece of metadata that gets included upon upload… How in the world does the metadata know where to go get the Customer.CustID from if the document type is agnostic, meaning it’s a type you can use anywhere? Is it aware that you’re attaching to QuoteHed and so logically there’s a tie to the Customer table and that’s how the Customer.CustID is possible within the metadata tables?? Or… @vleveris , after having read some things from you, is the metadata that actually gets uploaded with the attachment, when doing a file attachment in Kinetic, limited to the exact table you are attaching to i.e. only the metadata that referenced something in QuoteHed.* since that’s the table I am attaching to and all the other metadata that referenced Customer.CustID or Part.PartNum would get ignored. Having an odd time trying to understand it all. Are people having to use default workflows related to the content type in order to fill in metadata located in other tables than the table you are attaching to?
In short, looking for some help understanding metadata and how that exactly works in Epicor/Kinetic, and when there are limitations are people then running secondary workflows?
No. The MetaData must come from the same table that’s getting the attachment. I like metadata, I want metadata, but I don’t like the way it works. I’m leaning towards entering the metadata in ECM and then posting it to Kinetic.
You’d have to do it in ECM. There’s not a way to automatically add metadata that’s not available as a field on the table you’re referencing. At least not that I can think of.
Everything said so far seems to be accurate to the best of my knowledge. Document Types will only pull metadata from the table they’re attached to. This is severely limiting in what you can pull from Epicor into ECM in one shot. Also, there are several “calculated” display fields that aren’t available even from that table. Many CustID and CustName fields display based on how Epicor links data tables through the index value, like CustNum.
As such, we will often develop a custom workflow to pull the rest of the data we’d like. This is typically done via datalinks, whether those that come with an AP/SO license or a custom one. These could technically be added to the Content Type to skip the workflow requirement, but you’d lose exception handling.
I’d imagine a BPM, APR or something similar could be developed to run to send more metadata to ECM, too, but I’d argue it’s easier and avoids update issues with customizations if you do things through ECM.
Thank you @Mark_Wonsil, @chaddb, and @vleveris. I guess what bugs me is ECM has so much to offer for content management, using drag and drop functionality that can’t also attach meaningful metadata at the same time makes the document pretty “stupid” when it hits ECM. I think I’ll have to develop a workflow @vleveris if I want other data from other tables. I’m not too worried about exception handling at this time, but I can see how you would want to know if that workflow failed, but if it runs after the attaching process and keeps its content type, I don’t really care if it errors out. I’ll just have to review it.
I wish you could run a BAQ to populate the metadata which I suppose there is some way to do that on the kinetic panel card.
In any case, it seems I’m leaning towards a customization at some level whether that’s on the kinetic side or the workflow/ECM side.
I’m gonna hit @Mark_Wonsil with the solution as he was the first one to clearly and fully get me the answer I wanted, but I wish I could give each of you a third of the solution point haha. Thank you all so much.
If you want to have a generic Document Type capture a specific value, you have to map it in the Document Type Metadata screen.
As an example, if you have an Email document type, you can map it to multiple different tables/fields where you think it will be added. You have to know what tables are available on which screens to really set it to work. It is a lot of setup, but I also think it is about the same amount of setup in ECM, if not more.
This is what we do with common types. There are just multiple table entries in document type metadata. Depending on where it’s attached some are blank.
It is a lot of setup, but if you do it, it does work. Then all you need to worry about is your users selecting the correct document type. That is why I miss the classic interface where you could see all of the document types associated with the screen and then drag and drop onto the document type.
Facts. Set it up 6-7 years ago and it does just work. Just have to remember when you add a new ECM doc type in Kinetic go set it up in ECM. Or it just gets the default permissions.
I’ve found it fairly easy to fill in fields when using the attachment “drag and drop” feature. There are still bugs in Metadata so I usually just grab the Metadata fields that are important to identify what it is. From there, attach the Content Type to a workflow that brings the other information in that you need.
A quick example:
If you need Customer Name to populate on a document, you could send Company and CustNum as Metadata to use as parameters.
SELECT [Company]
,[CustID]
,[CustNum]
,[Name]
FROM [Erp].[Customer]
where Company=@Company
and CustNum=@CustNum
In the workflow, add a datalink that uses the above and output the name field.
Right, I just wish I could build it on the front end because as @vleveris had said the workflow is tough because if it errors out during the workflow the user won’t know anything.
For sure, I should have stated, wish it was out of the box… like you could link a BAQ to use to fill out metadata. And you’d link the BAQ to the primary table chosen in metadata.
I think @utaylor was wanting to be able to easily add fields in metadata that aren’t in the table. IE: add a customer name from Quote. You can add CustNum but not name.
