So, when you set up the workflow, it requires an existing Invoice group to be able to put the the invoice into. That’s fine, I can make the group.
However, Epicor deletes the group if someone posts all of the invoices in the group. Normally, that’s fine, but ECM is still expecting for that group to exist.
Obviously, training people to transfer the invoices out of the group into a working group is the “Right” way to do it, but it’s something that someone can easily forget that it matters. Plus, if you are moving flows from one environment to another, it seems like something you would want in place to take carry of a rather silly exception.
So my question is, does ECM have a built in way to check for a group, and if it doesn’t exist, create it? I looked through the integrations and didn’t see anything that popped out as something that would do that. It seems like a big miss to not have that ability.
This happens automatically as part of the workflows that come with the ERP AP Automation license. You can also change the names of the groups to be whatever you like to meet the needs of what you’re doing. Some of my customers have this setup so that each day’s invoices go into their own GroupID.
Could you provide a screenshot of the error in question? This sounds like new behaviour which shouldn’t be happening… The only GroupID related issues I have ran into is if a user is in the group so it is locked or if the GroupID name isn’t valid, according to Epicor requirements.
hmmm… Well I just pointed everything to live, so I can’t willy nilly drop in invoices like I had been, but I will keep an eye out and see if I can catch the error and get a screen shot. We are in “Live” testing, where users are feeding invoices to IDC manually and then making sure everything flows through ok. I have the workflows set up to be as much hands off as possible, and exceptions with matching just revert to a header only invoice so that we can get it into Epicor as soon as possible, as we have lots of dashboards and tools built up for visibility in there.
I have the flows set up to look for certain criteria and route to different flows based on what it finds, and it changes the group ID in the flow as it does that. I would assume that in Pre-Create or Create invoice, it should be doing the creation of the group if it doesn’t exist, right? (I couldn’t find a discrete step that did it).
But you could be right, and maybe I was basing my assumptions on previous error that I may no longer be getting, as I’ve just been careful about making sure the groups exists. I’ll talk to my testing group and see if we can set up a test to see what is actually happening.
Depending on where in the workflow this is happening and how that BPM is interacting with the same table, it is likely a valid error in that the GroupID does not exist. My assumption is that if you were to manually create that GroupID in Epicor and then clicked submit in ECM, that it would process just fine.
Well, yeah. That was my original question. It’s really easy to delete an invoice group, so I want ECM to create the group if it doesn’t exist. My test is that I deleted the group to see if it would create it (like you guys said it would). It works fine if the group exists.
@Banderson If the bpm was to make the group unique then you can make the group per user in the workflow. I did that so each processor does their invoices and then they can review the edit list and post them without causing another AP processor an issue.
Usually I put a few tasks to take date 012624SW as example with the initials at the end of the string.
I’ve found a sleep task could help with the exception that occurs when the group is locked, it will recheck when the group is unlocked, then if the group already exists and is locked / in process of posting, will recreate the same group again.
I didn’t think of the sleep task! That’s a good idea. We’ve had invoices created, but it’s the attachment that didn’t work. Clicked submit on the exception and it went through. If I add the sleep task, the automatic retry is even better. Love it.
There’s a Nuget package for .NET Resilience called Polly that codifies this kind of retry behavior among other techniques. It started as a private project and Microsoft has invested heavily in it as they use it in their own solutions.
