As reports I write tend to do, these reports were joining to the General Ledger via the GL Account Index Master (GL00105) table and then joining to GL Account Master (GL00100) for the account descriptions. I wrote the following script to check the two tables against each other to see where the problem lay (my suspicions were on GL00105 being corrupt as the accounts were being used within Microsoft Dynamics GP Continue reading “Fixing A Corrupt Account Index Master”
While I may have used FTP or similar if I had control of all software installed on the server, in this case the best way of doing this was to just use the Remote Desktop Connection and a local drive made available and copy the backups to this drive over the connection.
However, the colleague who was going to do this for me out of hours is not from an IT background like I am. He’s one of those Mark Polino laments the absence; a qualified accountant who has moved into a role as a Microsoft Dynamics GP consultant.
As he’s not from a technical background, there are some things I take for granted which he does not know of. I therefore documented the process of making a drive available over the RDP connection for him and I thought I’d post it up here as I thought it might be useful to others. Continue reading “Making A Drive Available Over The Remote Desktop Connection”
After initial acclimatisation pains with Microsoft SQL Server 2008 R2 (I largely skipped 2005 and 2008 RTM) I have become used to Management Studio and do now prefer it to Enterprise Manager and Query Analyser.
One of the things I really like about SQL 2008 R2 is the installation process where you pick the collation. Dealing with Microsoft Dynamics GP so much means I need to be careful with server and database collations as GP, once installed, cannot have it’s database collation changed.
We typically install SQL Server for Microsoft Dynamics GP using the SQL_Latin1_CP1_CI_AS (case insensitive, accent sensitive), which is very easy in SQL 2008 R2 Continue reading “Selecting The Correct Microsoft SQL Server 2000 Collation For Microsoft Dynamics GP”
I did some digging around the company database looking for the correct way to get the next Journal Entry number and found a function called glGetNextJournalEntry.
A little work and I was able to supply the following to the developer for him to wrap into a stored procedure to get the Journal Entry number and make sure there were no issues in GP;
DECLARE @l_tINCheckWORKFiles tinyint = 1
DECLARE @I_iSQLSessionID int = USER_SID()
DECLARE @O_tOUTOK tinyint
DECLARE @IO_iOUTJournalEntry int = 1
DECLARE @O_iErrorState int
SELECT @IO_iOUTJournalEntry AS 'NJRNLENT', @O_tOUTOK AS 'OUTOK', @O_iErrorState AS 'ERROR'
After completing the upgrade I tried to log into GP and received the following error;
After reading around and trying to work out the correct path, I decided the likely upgrade path would be GP 9 SP3 > GP 10 SP5 > GP 2010 R2, but I would try GP 9 SP3 > GP 2010 R2 and see if it would work (although I was extremely skeptical) as this would save some time on the upgrades if it was possible. Continue reading “Microsoft Dynamics GP 9 SP3 Upgrade Path To 2010 R2”
In two previous posts I discussed testing Microsoft Dynamics GP 2010’s new Email Remittance functionality; first, by setting up creditors with an internal email address and, then, by transferring the email address from the INET1 field to the new EmailToAddress field.
The other script which I used, and forgot to post, was the one which configures all of the creditors, who are not currently configured for email remittances Continue reading “Enabling Email Cheque Remittances For All Suppliers”
After checking out the other issues I’ve seen recently (Domain Trust issues, Windows Updates restarting MSMQ and timeouts) without luck I expanded the investigation. Continue reading “eConnect Messages Not Posting To GL”
A couple of weeks ago, a client was testing Microsoft Dynamics GP 2010 R2 and reported that some of their postings from an external system were not arriving in GP (these postings are transferred using eConnect).
When I installed eConnect I enabled Journalling on the econnect_incoming queue so we would have a record of messages which had been submitted. After receiving the error I went to make sure the messages had reached the GP server (Continue reading “eConnect Error: Unrecognized error 232 (0xe8)”)
The reason for this is actually quite simple, but I can’t help but feel it is a little bug like. Only payments made directly via Transaction Entry or those produced during the payment run (Continue reading “Missing Transaction In Cashbook Bank Management?”) are posted to Bank Management. If you need to do a manual payment into Payables, or a manual receipt into Receivables, then this needs to be done via CBM Batch Entry ( )