InvcGrp updatetable BAQ

I try to unlock invoice group using updatable BAQ. however, I receive an error message, please advise

With this case I don’t know if you can use BAQ Update. But I got 2 ways to do that.
1 - Call user to login, open this group and click on Clear button.
2 - Use SQL update.

I asked person to login and it released the locked group.
How can I tell which table/field can use BAQ Update? Why InvcGrup cannot?

There’s a BPM Erp.InvcGrp.UnlockGroup, which you could invoke from another BPM to unlock it.

I’m not familiar with invoke from another BPM, could you provide some example?

Here’s a down and dirty example.

I made a Post Proc BPM on InvcGrp.IsLocked. This fires every time an InvcGrp is fetched.

  1. Make a variable as shown above.

  2. The condition just checks to see if it is locked.
    You could add a row to it so that it only is true for a specific user (supervisor).

  3. The Show Message was just for debugging.

  4. The Invoke BO Method widget:
    with the configured params of:

Basically it just calls the BO method InvcGrp.UnlockGroup, passing the GroupID as an input (the group to be unlocked). I made the variable tempDS just to have something for the 2nd parameter. It’s never used elsewhere.
The above will unlock the selected group if it is locked. This will happen 100% of the time. So an improvement would be to add showing a BPM form to give the user the choice to unlock it or not.


It goes without saying that this should only be used as a last resort. If the user that locked it is unavailable. If that is the case, it would also be best to end that users session via EAC. That way they can’t have the same group loaded in their client too.

1 Like

I followed the example and I received an error. I guess I still not understand how to use invoke BO.

Hello, I was just wondering if you ever figured this out? I too was trying to make use of UnlockGroup() to unlock groups that were left locked by other users but it never seems to work - every time I call it on a locked group I get “InvcGrp is locked by another user” (which is an odd error, considering that I’m not sure when else you’d call this method other than when a group is locked :grinning: ). In any case, I’m just trying to figure out if this method is actually useful or if I just need to stick with manually clearing the ActiveUserId field in the database to unlock these groups.


Maybe UnlockGroup is normally called when you close the form (or unload that group). Which would be done by the user that locked it.

Perhaps there is a check to make sure the person unlocking it is the same person that locked it. When I wrote that post I probably only tested it on a group I had locked myself. Maybe tweaking the userID in the BPM would make it work.

There is no validation like this on UnlockGroup, the error is most likely in whatever the process for calling it is.

You can try using the Swagger page or Postman to call UnlockGroup and it will work.

Thanks @ckrusen for the tip! @Jonathan - on the contrary, it actually does appear that there is some check that the person unlocking is the same person who has it locked, as @ckrusen speculated. Testing this method call via BLTester while connected as the same user that has the group locked, the call was successful and the group was unlocked. Doing the same exact test while connected as a different user results in the error “group is locked by another user”.

@ckrusen I’m curious - in a BPM how would we adjust the context of the user that it runs as?

I can tell you for a fact that it doesn’t, do you happen to maybe have bpms triggering an update somewhere?

Unless something else is executing, if only UnlockGroup is being called, it should not care what user is calling it.

Very strange - nope, we don’t have any BPMs linked to that table… but UnlockGroup() does appear to behave differently depending on the user that runs it.

“Based on the user …”

How so? Does being a SecMgr affect it?

Does it only unlock when the user that locked it does it?

And as a stretch … Does it matter if the person who locked it is currently logged on?

Being a SecMgr doesn’t appear to have any effect - even as one, I cannot unlock a group that another (non-security manager) user has locked using UnlockGroup(). From my testing, it seems to only unlock when the user that has the batch locked calls UnlockGroup(). And it does not seem to matter if the person is currently logged on (I had tried even when the user that had the batch locked hadn’t been logged in for a while, and it still wouldn’t let me unlock it).

1 Like

I would suggest enabling server logging to see what else is being called other than UnlockGroup.

I did this exact same test, create invoice group with User1, InvcGrp.ActiveUserID is populated as User1, then through the REST API Help page call UnlockGroup logged in as User2, call is successful and InvcGrp.ActiveUserID is empty.

Hmm ok, I will try that and and also will try via the REST API instead of via BLTester or a custom form w/ custom code. One thing I did notice, checking the documentation in the REST API on APChkGrpSvc.UnlockGroup() is that it actually states “The user who locked the group only can unlock it”. This is different from APInvGrpSvc.UnlockGroup() which does not state this. Is it possible the same holds true for APInvGrp as well (perhaps in my specific version)?

This might be why we are getting different results, I was only referring to the InvcGrp BO, it is possible others work differently, I will check tomorrow.

EDIT: Yes, both APChkGrp and APInvGrp check ActiveUserID against Session.UserID and won’t let you unlock the group unless it is the same user.

I can confirm that using BLTester does not work to unlock an AP/AR group… did someone have found a proper way to do this? An UBAQ won’t work either since the upudate process validates if there is an active user…


any suggestions other than running an update sequence in SQL ?

Try passing the ‘OnBehalfOf’ header in the rest call as the user id that has the group locked. This might help