One of our clients had an issue this morning with using up the current number sequence in Sales Orders. The order type got to EW9999, and then didn't roll over to 1000 (that's another issue ...) This was updated manually and is now working fine.
Now when they try to run the Process Manager it will process one or two orders, and then crash with the message " Another process has already added the soplan item, the program must be terminated"
I've re-run the OM Integrity to rebuild the SOPlan table three times today, and each time it processes a couple of orders and then crashes.
I took a look at the SQL SOPlan table, and there are a few lines in there that were created today, that have no CpnyID and the planref = 0000. The rebuild doesn't appear to be getting rid of these. Is it safe to delete these lines?
Any ideas on what else might be going on here?
It sounds like there are some corrupted SOPlan records. You can delete them. If you still have the issue, try the steps below:
1. Stop Order Management Process Manager.
2. In SQL Server Management Studio run the following against the Dynamics SL application database
Delete from soplan
3. Access Order Management Integrity Check. Select the option to Rebuild Inventory Plan.
4. After Integrity Check is completed, restart Order Management Process Manager.
Technical Support Engineer
**This posting is provided "AS IS" with no warranties and confers no rights.
If you decide to delete the few lines and rebuild the Inventory Plan, stop Process Manager first.
We ended up installing a hotfix for it - it took a while to find as I was searching knowledge base for the error message. When I just entered SOPlan in the KB search the hotfix popped out. We've installed and it's definitely fixed the issue, although it seems to have blown up auto increment on Project at the same time. Thanks for the help!
Thanks for the information. Do you get an error on the project issue you describe? What do you mean by "blows up"?.
The auto increment is on the dept, the first 2 digits of the project number, and runs off 0DPT in the Code Files. When the user enters the dept and hits auto increment now, it either brings them up an xisting project, or it just comes up blank in the project number screen. When it does work, it appears that the departments are being asigned other depts number sequences. All a bit of a mess really, and we've not been able to sort out why. Of course, it works fine for sysadmin ...
Are you incrementing in Work Order or are you in Project Maintenance? Also, what version of SL are you using?
Are you saying this worked perfectly for all users just before the hot-fix or did you just turn on this functionality after applying the hot-fix?
I think this one is good now. Turns out (as it often does when you do some digging) that there were some users that were setting numbers up manually and messing up the sequences, as well as pulling the wrong sequences for their departments when doing so. Everything seems to be testing fine now and the users have all been reminded of proper policy. Thanks for your help.
OK, so we're back to having issues today. Anyone who tries to increment a project number is getting the same project.
Here's the user process :
-I go into order management
-I hit work orders
-in the project field I hit F3
-I click on insert
-I hit the auto increment box next to project
-In the division field I type 10
-I hit increment
-in the project field the number 30-103715 appears
All remote users are getting the same number. We all log on through terminal server.
The '10' she entered above is the department code used to control the increment. All the departments are set up in Code File Maint, and the sequences are all held there and appear to be correct.
I installed the hotfix from KB980917, as the circumstances are pretty much identical apart from accessing PA.FEN from Sales Order and not Work Order. No changes.
I'm thinking it is reading the same value over and over is the user(s) that are trying to increment the project IDs don’t have rights to update the SDG.ini file.
The location of that file will vary based on the operating system and version of SL. It might be in the windows folder, or it might be in a folder in the users profile, like c:\users\allison\appdata\roaming\Microsoft or something like that.
See if you can find the SDG.ini file on the terminal server and see if the users have sufficient rights to update that file.
Bingo! That was the issue. I had their system administrator add the domain users group to the permissions to that file, and the problem is solved.
Thanks very much for your help! Much appreciated.
Other Microsoft Sites
I'm a Customer
I'm a Partner
Use the official Twitter tags:
#MSDYNCOMM | #CONV13