Moving a DocStar (ECM) document to a New Package Slot

I am looking for some insight from any of you DocStar (ECM) experts out there.

We are using the PackageWorks Module in ECM and have a situation that happens where a Sales Order / Customer PO (SO-PO) document is created and Break Routed to ECM. This happens before I have the information needed to create the possible multiple packages from that Sales Order.

What I am trying to do is Get the Attachment file name (done in a datalink SQL view) and save it to the newly created Package Slot “SO-PO” after that slot is created. I am able to get the file name but don’t see an available ECM Task that will allow me to use that file name to add this ECM Document to a slot.

The Add to Slot task is triggered by a document workflow but does not apply here, I guess.
It is obviously possible to manually drag the SO-PO to the slot but that is what I am trying to avoid with this process.
I was able to push Revisions to the slot from The E10 Sales order when it sends the doc to ECM via Break Routing.

Any suggestions???

I’ve just got my packageworks license, so I’ve not played with it yet, but I know a few things from our conversations with the technical folks. So I may be a bit off here…

I would need some more information about that happens to the SP-PO document type when it’s created, but I think I’d start with that Doctype and it’s workflow. If it doesn’t have one, should it have one that creates the package? And if it does, should the last step be to add it to the package (and create it)?

I’ll assert that once a document makes it to ECM, you have everything you need, either immediately or via a Datalink back to ERP. And if there are multiple packages possible, then you will need a fairly complicated workflow to test the document against each package and insert it when appropriate in each package. (I’m assuming the package skeletons have already been created)
I would take a step back and outline the process you want. You can change doc types, trigger subsequent workflows, and change all kinds of things once you have a document in a workflow.

I think you are on the right track with this. Not sure why you say it would not apply? I think it’s the only task that would get you what you need, you may need to take a step back - outline what you want to happen - and then build the workflow(s) from there.

Remember, once the document is in ECM, you have - or can get almost anything you need via datalink - and workflows can change doc types to trigger subsequent workflows, which can change doc types back and retrigger the workflows, add to multiple package slots, add branch logic on almost any data, etc. There is a lot of creativity possible with the workflows.

I Have the process working with revision of the SO-PO file when sent to ECM via Break Routing. The workflow saves it to every package associated with the OrderNum passed via meta data. I would love to change doc types but must have missed that one in the task library.
Not sure where you are able to grab a Document that is already stored in ECM and change its type.

After reviewing the Task Library unless I am missing something I don’t see any tasks that allow you to specify the Title of the document… If you see one that allows you to reference a Document title please point that out to me.

Please remember I cannot create the Packages / slots with this initial version of this SO-PO. It is created when the SO is created and saved to ECM. The Packages are created after the Releases are entered into our Engineering Schedule and there may be multiple releases per SO. Again I want to pick up the existing ECM SO-PO and insert it into the Package slot after the Package / Slot is created.

Thanks for jumping in!

Search and Replace are the tasks you want I think…

Search
image

Replace
image

It’s “Document Name” and you can set it to a variable to be used in subsequent tasks if need be - where you can also do some text manipulations to change it’s name if you want.

And so now I’m definitely confused. Your first paragraph states you have a SO-PO document and it gets put into every package associated with OrderNum(s). You last paragraph says this is an initial version of the SO-PO and cannot be put into packages/slots. So you have one package for the OrderNum and then more packages for each OrderReleaseNum?

If I extrapolate, you want to collect the original SO-PO (the initial one) and put it into a slot in the subsequently created packages for the Releases? Chicken and Egg problem. At first pass, I’d save the initial SO-PO doc as a content type of it’s own - or leave it with the workflow you have now if you need a package for each of the initial SO-PO documents. Then I’d have the workflow creating the packages as the Release documents come into ECM and a step in there would Search/Add to Package the “Document Name” of the initial SO-PO document. Does that sound about right? If not, you’ll need to provide a process map or something :slight_smile:

Here is our Process

PO received from Customer
Sales Order Created.
Sales Order Ack Printed to PDF
SO Ack and PO combined to SO-PO “OrderNum” REV 0 and saved as DocStar Document via Print Routing
At this point the “SO-PO XXXXX REV 0.pdf” is the only document saved to ECM.

Then Project coordinator is assigned to the SO and creates Releases which enters these releases into our Engineering Schedule in E10

The PC creates an E10 generated Schedule Letter which will via Print Routing, execute a workflow in ECM to create a Package for each Release including an empty SO-PO Slot as well as any other slot needed for this release.

I can get the SO-PO title via a Datalink
select
XFileName,
DocTypeID,
XFileDesc as FileName
from Epicor10.Ice.XFileAttch as XFileAttch
inner join Ice.XFileRef as XFileRef on
XFileAttch.Company = XFileRef.Company
and XFileAttch.XFileRefNum = XFileRef.XFileRefNum
and ( XFileRef.DocTypeID = ‘SO-PO’ and XFileRef.XFileDesc like ‘%REV 0%’ )
where (XFileAttch.RelatedToFile = ‘OrderHed’ and XFileAttch.Key1 = @OrderNum)

The WF that creates the Package / required slots for each Release, is where I want to use this File name found in the Datalink and store in the newly created Package Slot “SO-PO” .

So I don’t get where you can reference this file name which I know is going to be present in ECM and execute a work flow on it? How does the Replace know it is executing the Content type change on the document that has the Filename found in the Datalink above?

If subsequent revisions of this are Sent to ECM via Print routing I can save to slot because the Content Type is picked up and executes a WF to save this doc using the same WF loop used to create all the packages. This works…

Ok I think I see it now. You want to add the “SO-PO XXXXX REV 0.pdf” document to each release package created by the Schedule Letter created, in the SO-PO slot.

Going on this, I see where you are stuck. The workflow is for one document, and at the time it is running you are working with the Schedule Letter. There is not (that I can find) a task to allow you to perform an ‘action’ on another document except for “Search and Update”, and that only allows for changing the Content Type metadata, not the system metadata like $ContentType or $WorkflowID. And, the package related tasks seem be lacking this ‘add another document’ function as well.

Ok, so ‘out of the box’ time…

Do you have the ECM API License? In theory, I suspect you could cause the Order-Release creation (via BPM custom Code widget or Function) to cause ECM to what you need either by finding an API function that would allow you to put the SO-PO XXXXX REV 0.pdf into the package slot, or to push that SO-PO XXXXX REV 0.pdf document into another workflow. Since the API mimics the UI, and the UI allows what we are saying, it should follow.

OR

Could the Schedule Letter APR process cause the SO-PO XXXXX REV 0.pdf document to print again, but force the output to be a particular folder location, which the ECM Client (the tray based utility) could pick it up and run a workflow? That workflow could test if the Document Name already exists and therefore not ‘keep it’ but rather cause it(the original one) to be added to the appropriate package?

Some thoughts, as I can’t let a good challenge go without a solution…

I looked and see the API (boolean) is disabled. Is that the line that would tell us that we have API license?
Is there a list of ECM API functions somewhere to view?

I have not used the ECM Client for anything in the past. Do you have an example of a process you performed to illustrate this?

Thanks for chiming in!

Yes, that is the line that would say enabled - as our does. However, I’ve not actually done anything with it yet. We were thinking of a MS Power Automate script or something like that.