We’re working on a large integration with our Epicor system and everything we’ve needed to do using the API has been successful…until we wanted to post AR Cash Groups.
The cash group/cash receipt are created (with detail) and I can successfully post via the GUI, but I can’t find the API/Rest call to post the cash group.
I found the PrePostGroup call api/v1/Erp.BO.CashGrpSvc/PrePostGroup but can’t find the one to Post Group directly and need it.
Have you completed a trace log in the GUI to see what methods are called during the posting procedure. I am not sure if you can initiate this level of execution in REST since it is a server side process I think.
The Erp.Proc.CashRecPostSvc in REST is what you need I think. I am not a REST programmer, so not sure this is what you will need, but based off your details for the BO, I believe this to be correct. There is a SubmitToAgent post option in there.
I’ve got it sort of working, but I’m having problems with Erp.Proc.CashRecPostService SubmitToAgent. It fails frequently, and fails in two different ways.
Sometimes SubmitToAgent returns an error about database deadlock, but if I set a breakpoint and go look in Epicor when this error occurs, the group has actually posted. I’ve seen this database deadlock error before when we were calling Db.SaveChanges() in BPMs, but we’re no longer doing that, and we never had any customizations related to cash groups.
And sometimes I don’t get any error from SubmitToAgent, but the group doesn’t actually post. Nothing seems to be wrong with the group, because I can go into Cash Receipts Entry and post it manually.
I have a hunch that it might have something to do with the AgentSchedNum and AgentTaskNum parameters, whose meaning I do not understand.
I don’t know how this works, my only suggestion would be to enable trace on the client, if possible logging on the server as well and see what parameters the client sends to the server.
I’m also not sure what is the purpose of the Async method, as far as I know submitting the process should not be an expensive operation enough to do it asynchronous, since it is the task agent that will pick up the task and actually execute the process.
Sorry, the Epicor method is actually called SubmitToAgent. The REST client generator I’m using appended Async to the method name. I edited my above comment accordingly.
I may have solved the problem by introducing a 2s delay between creating the cash group and posting it. It might have been some sort of reading your own writes problem. It hasn’t succeeded enough times yet to be sure.
No dice. I’m still getting database deadlock errors even with delays. And when it doesn’t deadlock, the completed tasks are never marked complete in Ice.SysTasks.
This might be why my predecessor used an insane hack to post deposits. Instead of using the REST API, he was dynamically loading Epicor DLLs into our integration and invoking methods on them to create sessions and submit deposits to the task agent.
Just out of curiosity, why not use Bank Statement Processing? It brings all bank transactions in and allows one to post cash as well as other transactions. You’re going to have to balance at sometime so why not do it all in one fell swoop?
How many groups are you posting? How often are you posting them?
Can you do a SQL profile setup to see where the deadlock is happening?
Do you have BPMs around the cash receipt posting process?
As long as the posting is being submitted in REST the same way the regular client does it it should work the same, unless there’s some obscure bug out there.
I’m posting groups around 10 seconds apart, or 30 seconds apart with artificial delays. I can manually post groups 5-10 seconds apart with no problem. There are no BPMs around cash receipts.
I tried replicating what I saw in the trace log, as well as what my predecessor was doing with Epicor DLLs. The differences include the name of the MaintProgram being called (“Epicor.Mfg.UIProc.CashRecPost” in the old code, “Erp.UIProc.CashRecPost” in the trace log) and whether DateFormat, NumericFormat, and WorkstationID are set on the CashRecPostParams. In the trace log, WorkstationID was set to my Windows machine name, not a valid Epicor workstation ID. I tried various combinations of these differences, but it seemed to make no difference in the frequency of deadlock errors.
When I get a deadlock error, I wait 5 seconds and call Erp.BO.CashGrpSvc LeaveCashGrp. This silently fails 80-90% of the time, leaving the group locked. If I leave the group without trying to post it, it always succeeds.
This seems to be part of Solution Workbench which I have very little experience with.
Seems odd that this would fail when posting cash receipts, you would think it would also cause issues with regular postings through the desktop client.
I think I’ve got it! Solution tracking seems to be associated with workstations, not users. Although my predecessor’s hack didn’t specify a WorkstationID, and the trace log shows the UI using a fake one, setting a real WorkstationID in the CashRecPostParamRow seems to have solved the problem. I never would have guessed that this had anything to do with solution tracking if not for the SQL profiler, so thanks for mentioning that.
The problem was related to solution tracking, but not in the way I thought. Specifying a WorkstationID might just have been voodoo. The real problem was that the Epicor user making the REST calls was tracking to a solution. I had logged in as this user, and it didn’t appear they were tracking to a solution. But the user was associated with a solution in Ice.SysUserComp. Apparently it’s been this way for years. The name of the solution it was tracking to indicates that it belonged to my predecessor, who also set up the user for REST integrations.
This might never have been a problem, except that there’s also an issue where certain actions cause solution tracking to record garbage in Ice.SolutionTracker. When you open any solution in Solution Workbench, it cleans up these junk entries on all solutions. My Ice.SolutionTracker table had over 150,000 lines of this garbage, and it was evidently bogging down. Opening a solution took several minutes, then crashed. Opening it again took a few more minutes, and finished deleting those 150,000 lines. The deadlocks stopped. Just to be sure, I cleared the SolutionID from the integration user in Ice.SysUserComp. The number of rows in Ice.SolutionTracker is no longer growing every time my integration runs.
Was the solution related to Cash Receipt? I don’t know Solution Tracker but I still have no idea why making a rest call would log/track something unrelated.
Solution Tracker records a bunch of unrelated things for many different operations. I have a ticket open about it. I was able to reproduce recording junk in Ice.SolutionTracker by creating a sales order in the UI. Solution Workbench knows these rows are junk because it deletes them when you open a solution. The problem comes when a user inadvertently leaves solution tracking on, as my predecessor apparently did on our REST user. It records junk rows for everything they do, and when Ice.SolutionTracker grows to a couple hundred thousand rows, things start blowing up. So it turns out I kind of hijacked this thread, since my problem wasn’t specifically related to posting cash receipts in the REST API. That was just the first thing that started blowing up.
