I recently fielded a call from a client who had copied their live database across to test so they could do a reconciliation of Purchase Order Processing accruals to the General Ledger accrual account without having to chase a moving target as new transactions were processed.
This was only discovered after the client had tried to post some batches to get the figures onto the GL for registered batches. When checking the transaction edit list the following error message was displayed;
However, when I tried to post some of the batches they posted without error. After discussing with the client, I established that running the edit list cleared the error and allowed batches to post.
I did some digging and, between the client’s IT department and I, we established the problem. The client’s IT department had configured a SQL Agent job which copied the live database over and ran the Microsoft supplied scripts to change the INTERID on all tables. However, there was an error in the script which ran the InterID script against the Master database isntead of the test company database; which meant the InterID was not changed to TEST from LIVE.
Microsoft Dynamics GP therefore regarded the pending batches as intercompany as they contained an InterID of LIVE when the database was TEST. I went back and ran the script and checked the transaction edit list but received the same error message.
It appears that a flag was set against the database that the transactions were Intercompany ones and this flag was not one of the standard flags (such as ICTRX and ICDISTS on GL10000 and INTERID on GL10001). The client was pressuring to get on with his reconciliation so I couldn’t spend too long looking on the database (I intend to reproduce this error so I can chase down the flag for future reference) and needed a solution quickly.
Knowing that printing the transaction edit list allowed the batches to post, the quick solution to the problem was to run a transaction edit list for all of the registered batches. In Microsoft Dynamics GP 2010 this can be done using the General Ledger Batches Navigation List; unfortunately, it produces one report per batch and I had selected report to screen. Which meant I had to close 146 reports.
Once done though, all the batches did successfully post allowing the client to continue with his reconciliation.
What should we write about next?
If there is a topic which fits the typical ones of this site, which you would like to see me write about, please use the form, below, to submit your idea.