You could with a workflow in ECM. But out of the box they only allow mapping on fields on the specific table you’re attaching too. It’s rather limiting.
1 Like
@chaddb is right, that’s what I want and with some custom coding I’m sure I could do it.
1 Like
I used Data Directives on XFileAttch to add additional attachments to additional tables when a document was added to another table. I would look at maybe putting a DD on XAttachMetaData to do what you want.
1 Like
yeah, just would need to figure out timing as to when it sends over to ECM.
We do this to send attachments to multiples places. IE: We copy certain attachment types to orders from quotes or something from a part to a Quote/Order. It does work.
1 Like
@utaylor , it looks like you want to put a Pre-Processing on DocStarUploadFile. It has the metadata in it, so you could easily capture what you can and use that to look up what you need. I would even go so far as to add a Function library that ingests the dataset and gets routed to the correct function based on the file type.
2 Likes
My man. That’s a good idea.
Dang - that’s about brilliant sir. Must tuck that one away for future use.
@utaylor I’m late to the party - but I wrote every one of my workflows to take the minimal transaction data and use a datalink to go get everything I want in ECM. It keeps me out of custom code or extra BPMs and doesn’t limit me in any way. As @chaddb and @jkane have already said - many ways to get things done - just depends on your prefences.
2 Likes
My thing is, what if for some reason one of those workflows or datalinks fails or something on the back end breaks, who is looking into that, you?
Also, did you make a “folder” structure for your documents or did you let them sit at the root level of APINV or QuoteHed, etc.
You could stop the transaction and not let it go through? Or you could log the transaction to a UD table?
Yes, technically possible. You’d have to build in for that. Our simple version of the process logic says that if the attachment comes from Epicor, then a transaction exists. If the transaction exists, then the base data available to be retrieved exists. The ‘extra’ data may not exist and the workflow allows for a ‘wait’ statement to be used to ‘wait’ for more data to exist before it proceeds. In addition, if you test a few fields for validity and one or more fails, you change the document status field and the workflow stops.
As with any headless processing, a human ‘head’ must eventually check up on it.
Minimally - Company/ContentType is the folder structure - because it mirrors our security structure. So it’s easier to make sure the destination folder sets the security (a checkbox says “inherit security” on the Chenge Folder task)
1 Like
Right on, thanks a ton Mike, so you’re saying you add a wait task when the extra data has yet to be entered… like if you’re waiting for invoice data for an order you have a wait task on that order attachment until the invoice data is retrievable, am I understanding this right?
We did the same.
2 Likes
to be clear - we do not do this - but the functionality is there. I was suggesting it because it seems like it’s part of your issue/concerns with doing it from the ECM side versus the kinetic side. Maybe I misunderstood.
But yes, there is a wait task - I think you should explore it more before taking for granted it’ll do it. It may need to be built a certain way because of the checks that it does. Technically there are two tasks - “wait” and “wait for data” and they behave slightly differently, and the workflow blocks have to be built a certain way.
1 Like
I don’t think I’d need that for what I’m trying to do with the basic attachments in Epicor under the OrderHed or QuoteHed, etc. I just want additional things like customer name, etc.
2 Likes
Exactly what I do too. A datalink for Customer, sales person, territory, part #, site/warehouse, customer PO # (or reference #). Just the basic stuff that allows us to search for things in ECM.
1 Like
This is the painful part about how the data tables are connected in Epicor but displayed differently within the programs. Eg. CustNum is the index value that connects the Customer table to the Order Entry table, but users only see the CustID and CustName on the UI. Those data values aren’t available to pull as metadata when attaching a document to the OrderHed table.
For attachments that come over from Epicor, they are only added to a single table by default. This means that if you add it to the OrderHed table you won’t be able to send the OrderDtl data or Customer values. The way I’ve always handled this in ECM is to create a basic workflow to pull in the data from those other tables based on the initial captured metadata. I prefer a workflow to accomplish this, but it can be done in the Content Type or other methods as listed above.
2 Likes