Integration Manager. It seems that most either love it, hate it, or fear it. I’d venture to say that most fall into the “love it” crowd, and if you hate it, you probably have your reasons. (Hopefully, this article helps you to hate and fear it a little less by giving you a few ways to troubleshoot your problems when they arise.)
If you’ve used Integration Manager before, you know that sooner or later you will run into a problem on an integration. These errors can have a plethora of causes: it could be a third-party application, an improper mapping, or Integration Manager just wants you to join the “hate it” group and decides not to work at all. At any rate, when any of these happen, there are a few things that you can try to troubleshoot your problem. In this post, I am going to cover a recent Integration Manager error I came across, the article that helped me fix it, and my actual resolution.
The Problem: It was a Thursday afternoon and I was minding the queue while working on a few projects. In comes an Integration Manager case with an error I’d never seen before:
“DOC 10 ERROR: Microsoft.Dynamics.GP.eConnect: Number = 1245 Stored Procedure taPATimeSheetLineInsert : Description = UPR MSTR Pay Type record does not exist”
To top it all off, this was a payroll issue, (as you’d probably guessed by the error message). The error was occurring for a client at the point of their timesheet integration. Being payroll time, it was a hot case. I’m not exactly “Rich Uncle Penny Bags” myself when I do get paid, but when I don’t, I find myself reconsidering minimalism as a way of life. Needless to say, this error needed fixing and fast.
Looking at the error, I could see that it referenced the stored procedure “taPATimeSheetLineInsert.” The logical thing was to head on over to the client’s database and take a look at this stored procedure to see what it was trying to do. After scripting it to a new query, I could tell that there wasn’t a whole lot of valuable information to be found here, although it did point me in the direction of the UPR00400, the Payroll Pay Code Master.
I took a look at the UPR00400 for the employee in question, but found that this employee had a record for each pay code noted in the integration file. Close, but no bananas.
Looking For Help: Despite having worked in Microsoft Tech Support before, I had never seen this error. Sensibly, I went to Google (*ahem* Sorry, Mr. Gates), I mean Bing. A few quick searches later, I found an article on troubleshooting Integration Manager.
I’d seen this article before, but never really delved into it. However, it was written by a Microsoft Senior Support Engineer, so I had complete faith in the wisdom it had to impart. One thing the article mentions is creating an IMTraceLog file. I headed over to the installation folder to make the requisite changes. After restarting the whole process and bringing it up to the point of the error, I looked for the log, but there was no log to be found. I double-checked the settings in the IM configuration file, and they were also correctly set to log. This was a hot issue, though, so I didn’t spend too much time figuring out why the log wasn’t being created. (In retrospect, it could have been that the configuration file I modified was local when the machine was actually accessing a shared Integration Manager code folder.)
I knew that the “DOC 10” part of the error referred to a specific employee record in the header file. We probably could’ve fixed it by taking out the lines referring to him, but then the poor bloke wouldn’t have gotten paid. My next step was to see if GP would recreate this error when entering a timesheet manually. I adjusted the dates and other settings to mirror the import, and then tried to enter in the three line items for this employee. The first two lines went fine, but when I tabbed off of the third line, it errored out. Aha! Now I knew what I needed to do!
My Solution: I exited out of GP and started up a Dexsql.log. I then logged back in and reproduced the error. The final entry in the log I saw was telling me that it was looking for pay code 1140 in the UPR0400 for this employee but wasn’t finding it. So that was it. Turns out the Cost Category ID TVL in the transaction detail file had been incorrectly noted as pay code 1120 when it should’ve been pay code 1140 according to the setup.
I went over to the Employee Pay Code Maintenance window and found that this pay code (1140) had never been assigned to the employee. Once I assigned it to the employee, I called the client to have them test, and they were able to run the integration without further issue.
