Attachment Metadata - Limited to only 1 table?!

When setting up an ECM (DocStar) attachment type (Purchase Order) and then setting up the Attachment Metadata for what gets pushed into DocStar, I’m struggling to get some very useful information like the VendorID. POHeader only has the (useless) VendorNum, and normally I’d just link to Vendor table to get VendorID, but it almost seems like that is impossible with Attachment Metadata and you can only pull fields from a single table!?

image

I tried using the same Document Type but a different table, hoping Epicor would figure out the link in the background using it’s information about related tables:
image

But it seems to still only pull metadata for the one table I’m attaching too, POHeader:
image

There is so little documentation (that I can find) about this overall process / options for hooking Kinetic up to ECM. Anyone have some insight?

As far as I know, one can only pull from the record being attached. This is true for SharePoint attachments as well.

1 Like

I believe the ECM Gurus @MikeGross & @gpayne use queries from ECM to Epicor to get the data. Basically, you select the fields you can (VendorNum) and after the file is added to ECM, you somehow query back to Epicor to get the rest of the data. They could tell you more.

1 Like

@jkane is correct. You can assign the ID in ECM, just not from Kinetic.

Yep - I create a meta-datalink for every document type coming from Epicor and use the key fields (company plus trans/cust/PO/SO/job# ) to go back into Epicor and get the rest of the metadata I want to be able to use in ECM.

It works rather nicely!

Ah, okay @MikeGross - that should work, although I wish Epicor just could do it since it already has all the information about related tables, fields, etc.

Question: do you have a Workflow setup then for every document type coming in from Epicor, or am I forgetting a way you can have it just run a query to fill in fields outside of a Workflow?

Thanks everyone for confirming.

Yes - but they are a little special in that they are designed to be universal. A single workflow can apply to documents that come from Epicor, from IDC (PDF + XML) or from the ECM Client Batch input. The first action block has a check for a sysrowid guid and if so, then I have a datalink that uses that sysrowguid to go back into epicor and find the transaction metadata. If there is no guid, then either OCR/XML or something has to get me the key transaction data and then a datalink uses the go back to Epicor for the metadata.

So, really have two datalinks and a single universal workflow. Ok, technically three as one is for looking into the test database… I keep ALL my datalinks in both the Prod and Dev ECM envirnments.

image

3 Likes

Awesome info, thanks Mike!