When running PO Suggestions, the process task immediately ends with status = CANCELLED
Any idea why or where to look?
More info:
The SysMonitor history shows:
The History -> Report Detail and History -> Report/Task Logs tabs show no information.
Other reports and processes complete normally.
Have you looked in the Event Viewer on the Server under Applications and Services Logs - Epicor ICE Task Agent Service? Sometimes that gives you more information to track down the problemâŚ
The Event Viewer for App -> Epicor ICE Task âŚ
UAT_102300: An error occurred trying to run task ID 169640 for agent SystemAgent on the application server (User: manager, Task Description: Generate PO Suggestions).
Error Detail:
PROGRAM CANCELLED
I ended up just deleting the task via SQL (suggested in another thread)
I think the cause was from the fact that it was in our Test DB, that was made from a copy of the Production DB, while Generate PO Suggestions was processing.
So the Test DB ended up with a record for a task that was started, when no task was actually running.
Any update on this?.. it is happening to me now.
When you hit the cancel button in System Monitor a record is created in table Ice.SysTaskKill, process/report logic frequently check for this table to see if the user cancelled the process.
Maybe somehow there are records in ICe.SysTaskKill for TaskNums that havenât been submitted yet, so anytime you submit a new one and the TaskNum is already in SysTaskKill it immediately goes to CANCELLED status.
Seems very unlikely but I havenât really seen any other reason. As someone else mentioned check server logs, if they are not enabled do it through AppServer.config, and also check Event Viewer.
So IDK if this issue is unique to us but it looks like our issues was:
âthe scheduled tasks are somehow using the old âprintâ user for these tasks. But that print pw gets wiped out in the SysAgent record, so I found a query to put that pw back in the table, restarted the task service & it now seems to be working fine.â
I do wonder if there is a best practice around âsystem usersâ like manager and print?
Why using a query instead of going to System Agent entry?
I wanted to add to this post with what fixed my PO Suggestions resulting in âCANCELLEDâ because it wasnât instantly obvious to me what needed to be done to fix it.
I installed the latest ERP10 version in a Test Environment and brought in a copy of our Live Database. When I first logged in as my EpicorAdmin user it instantly forced me to change the password and of course I couldnât re-use the same password. (Donât Judge. 
) Iâm not sure why it forced me to do this right away when I first logged in but I had to change the password when I initially logged into this new environment.
Since I had slept since then, I kind of forgot about changing the password for this account. I then decided to try to test the Generate PO Suggestions and MRP processes and for some reason they kept instantly going to a âCANCELLEDâ state in my System Monitor.
I kept looking at my AppServer Task Agent Configuration (deleting, uninstalling, re-installing) and System Monitor Tables (clearing out unneeded records) but nothing I did fixed it. I eventually realized that it was my System Agent Maintenance record that had the wrong Password for my EpicorAdmin user in the System AppServer settings. I forget about this record because usually you set it and then never have to look at it again.
Iâm actually surprised that the SystemTaskAgent is still using an Epicor User and Password verses Windows Authentication. It would be nice if this could be changed to use Windows Authentication and that way, when I am forced to change the password on my Epicor Admin User it wonât affect my SystemTaskAgent. Just an FYI on what fixed this issue for me. 
We have specific E10 account just for the System Agent (as recommended by the E10 installation instructions).
And didnât set the password in Sys Agent Maint:
Well that is strange. If I leave either/or User Name and Password blank in the System Agent Record it says that they are required. And updating the password in that location is what fixed my problem when everything else I tried failed to⌠
I probably should have mentioned that we use Windows endpoint binding. No one even has to enter a E10 username or password. The E10 accounts are associated with domain\usernames. And the program always logs you in as the user logged into the workstation.
Yes, we are setup the same way. 
Is the Password there, it just isnât saving as ******** ?
