Not so long ago we all were busy voting for a product suggestion initiated by Mariano Gomez.

And here we are, with a wonderful utility developed by Tim Gordon from Alpine Limited called DexSense. This application runs as a system tray application and it shows its functionalities once you open a Dynamics GP dictionary in Dexterity.

You can download the current build for this utility from http://www.alpinelimited.com/Products/DexSense_16.zip

Take a look at some screenshots below for having a glimpse of the same…

Selecting Field Names:

Selecting Window/Form Names:

Selecting Table Names:

Selecting Procedure Names:

I am sure the entire Dexterity community would be benefitted by this work and I, on behalf of the community would like to thank Tim for his effort in giving this amazing product to the community. I would request the entire community to use this, test this and help us enhance the capabilities of this product. Good job Tim…

Until next post…

For many years now, I am sure every Dexterity developer has been dreaming of a cool IntelliSense feature to be provided in Dexterity. With the ease of coding brought into Visual Studio and this emerging in SQL Server from v2008 too, the dream to have this available in Dexterity too, has doubled up, I am sure..

Mariano Gomez has taken the initiative to submit a product suggestion for the same to Microsoft and we would recommend all Dexterity developers to vote for this recommendation, so that our voices are collaboratively heard and answered.

Please take a look at Mariano’s article Dexterity and IntelliSense for more information and vote for this suggestion.

For those who has issues accessing the URL because of permission issues, please follow the steps below.

• Go to https://connect.microsoft.com/ and login using your live credentials.
• Once logged in, in the search Products tab, enter Microsoft Dynamics GP and search
• The search will return 1 record. See the Your Status column. You would have an option to enroll. If not enrolled, please enroll. Once you have enrolled, go to the main page and search for Dynamics GP again and see the search result showing a status of Enrolled. Then click on Microsoft Dynamics GP in the search results.
• Click on Search Existing button to search existing product suggestions.
• In the “New Feedback for this Connection” section you would note the suggestion titled “IntelliSense implementation for Microsoft Dexterity”.
• Click on this product suggestion link and then you should be able to vote.

I hope we use this opportunity to join our hands and vote for this… And hope that our voices are heard.

Until next post!!!

I ran into a very interesting issue today, which I would like to share with you folks, which would be surely helpful to all who is involved in deploying customizations as chunks and packages.

We had an developed a customization for one of out clients, about 6 months back and now they had requested for an enhancement. We worked on this enhancement and was testing the deployment and landed into this issue explained below.

We had one of the temp tables modified by adding an additional key for validation purposes. As a standard process, I deleted the existing customization dictionary file and the copied the chunk file to the folder and launched Great Plains and included the new code. However, as I was testing the enhancement, I received a key error on the temp table which we had modified. So I looked into the Resource Descriptions to see the table key definition and noted that the new key that we had added to the table was not showing from the table definition. I then re-created the chunk file again and the same issue again.

Wondering what could be the reason, I tried to deploy the chunk on my machine and interestingly it worked fine and no issues. When I looked at the table definition in my local machine, it showed me the new key which I had added. Now a little more surprised, I began to analyze what could be the issue. Since this was a temp table, SQL Maintenance was not an option, since temp tables do not get listed in SQL Maintenance. 

I then had a chat with David Musgrave who requested me to delete the OLFD*.dat and OLFD*.idx files from the Data folder in Dynamics GP installation folder. These files are the cache files for the resource explorer. Once you delete these files, when you open Resource Explorer in GP following this, it will rebuild the resource explorer cache. I also deleted the .dat and the .idx file relevant to my product ID. The resource explorer cache got rebuilt but the issue still pertained.

Being really confused what could be happening, I was checking with David what else could be wrong. It was at this juncture that David asked me to check if there was any modified forms (or) reports for my customized dictionary. When I checked up, I noticed a modified forms dictionary in the Data folder. And then he requested me to rename/delete this modified forms dictionary and then try. And trust me, it worked fine when I did that. That’s when I realized that the client had modified one of our windows and created a modified form. And I realized that this modified forms dictionary would have the older resources which could have caused the conflict in the table definitions with the new customization dictionary.

So as a summary for all folks who are in the team deploying customizations, please keep these points in mind when preparing your deployment instructions:

• Delete any existing product dictionary from the application folder.
• Delete any .vba file for the specific customized product from the application folder (ensuring you have a customization package file for the VBA code so that you can import them back after deploying the new chunk)
• Delete/Rename any modified forms & reports dictionaries for the customized product (ensuring you have a customization package file for the modified forms and reports so that you can import them back after deploying the new chunk)
• Delete the *.dat and *.idx files from the Data folder for your specific product. These name of these files will be the product dictionary file name.

I hope this article is useful for all of you, and thanks to David once again, who has been my life saver twice in the last couple of days.

Until next post…

I was in the process of upgrading one of our clients from Microsoft Business Solutions Great Plains v8 to Microsoft Dynamics GP SP4. The upgrade process went fine, but after the upgrade was completed, I landed up at a strange issue where none of the users were able to login and they were getting the following error at the time of login.

However, the ‘sa’ user was able to login successfully without any issues. Once I tried to reset the password from the User Maintenance window, the user is able to log in without any issues. Wondering what could have gone wrong, I turned to the ever reliable David Musgrave to see if he had an idea on why this happened. He immediately directed me to his blog article which talked of Why does Microsoft Dynamics GP encrypt passwords?

This article threw some light on the password encryptions in Dynamics GP 10. It looks like the password encryption algorithm has changed in Dynamics GP 10. Hence a user enters the password in Dynamics GP 10, the application encrypts the password using the new v10 encryption algorithm and sends it to SQL Server, which causes the GP login to fail, because of the encryption algorithm mismatch between v8 and v10.

However, there is a work around which can overcome this functionality in GP and make GP v10 use the old algorithm to encrypt the password. This needs an update to the Dex.ini file. You can add the below given property line towards the end of the Dex.ini file.

SQLLoginCompatibilityMode=TRUE

Save the Dex.ini file and launch GP and now when the user tries to login using his old password, it allows him to login, but prompts him to change the password during his initial login. The user can change his password and continue logging into Dynamics GP v10 without any issues.

Note: Once all the users have changed their passwords in the initial login, we can remove the above property line from the Dex.ini file.

I should definitely thank David Musgrave for this tip he provided me, which helped me resolve the issue in a jiffy. I hope this article is helpful to all.

Until next post!!!

Recently, I was working on the year end for one of our clients and landed up in the error shown below during the YEC process for the General Ledger.

Based on the error message, I believed it was some issue in GP’s Year End Process. But on analysis, I found out some interesting information, which gave me some insight on how the year end process works when Analytical Accounting is installed and configured to include dimension codes during the year end process.

As you all know, during the YEC process, GP creates a journal entry for rolling forward the balance sheet account balances and to bring forward the retained earnings account balances (based on P & L balances) into the subsequent year. And Analytical Accounting process is triggered after the standard GP’s YEC process to create the relevant AA records in the AAG30000 series of  tables for the BBF(Balance Brought Forward) journal entry. It also moves the open year records from the 30000 series of tables in AA to the 40000 series of tables.

But in certain cases, we could have a GL account in GP which has a zero balance at the account number level, but they could have balances at dimension code level. E.g. An account 000-2300-00 could have a zero balance at the account level (from GP’s Summary Inquiry window), but they could have a debit balance of $1000 with a dimension code AAAAA and a credit balance of $10000 with a dimension code BBBBB. In such cases, even though GP’s BBF entry does not have a brought forward entry does not have a distribution line for this account (since account balance is zero), Analytical Accounting module appends an additional line into the BBF journal entry with both the debit amount and credit amount as zero. And in the AA tables, it inserts the appropriate balances brought forward at the appropriate dimension code level.

So consider this scenario: If there are 10 GL accounts in a company out of which only one GL account has a balance to be rolled forward. 5 accounts have zero balance at account level, and zero balance at dimension code level. 4 accounts have zero balance at the account level, but have a balance at dimension code level. In this scenario, GP would automatically create the BBF journal entry with one distribution line bring forward the balance of the 1 account which had a balance to roll forward. However, for the other 4 accounts with zero balance at account level and a balance at dimension code level, Analytical Accounting module tries to identify the journal entry number created for GP during the year end process, and appends 4 additional lines for these accounts with both credit and debit as zero to the specific BBF journal entry, and updates the AA tables with the relevant dimension code balances for all the 5 GL accounts rolled forward.

Further, in the same example above, if all 10 GL accounts had a zero balance at the account level, but had a balance at the dimension code level, GP does not create the standard BBF entry at all… In this case, the Analytical Accounting module tries to identify the journal entry number created by GP for the BBF and it identifies a NULL value (since there was no journal entry created by GP). But  Analytical Accounting still append lines for these accounts with a zero balance at account level, but a balance at the dimension code level, to the BBF journal journal entry (with a NULL value). Thus the above error surfaces. Ideally, Analytical Accounting module has to create the BBF journal entry from scratch, but instead, it looks for a journal entry already created by GP and tries to append additional lines to a journal entry which does not exist, which causes this issue.

I had to figure this out after digging into the YEC procedures in GP and Analytical Accounting. The SQL procedure which is causing the issue here is aagYearEndCloseMain. A ticket has been logged with Microsoft on this who has assigned it to the development team to have it fixed in the subsequent service pack/hotfix.

However, since we had to close the year in the interim and could not wait for a response from Microsoft. So this is what I had performed as an interim workaround to close the year without the above issue. I identified 2 balance sheet accounts (could be any BS account) and created a reversing journal entry in the specific company with a transaction date as 12/31/2009 and a reversing date as 01/01/2010. I debited one balance sheet account to $0.01 and credited the other balance sheet account to $0.01. Once I posted this entry, the YEC process identifies a balance of $0.01 in both these balance sheet accounts to be rolled forward and GP creates a journal entry during the YEC process, which will facilitate the AA procedure to successfully append the additional lines for the accounts which have zero balance at the account level, but a balance at the dimension code level. Also since we posted the entry as a reversing entry, the $0.01 balance which was rolled forward during the YEC process, into the 2 balance sheet accounts, would be cleared on 01/01/2010.

Trust me, this idea struck my mind, as I was having my breakfast listening to music… And for the fact that I was breaking my head for the last few days on identifying an interim solution for the same, it is quite amazing that i found a solution when relaxing… . Following the path of Archimedes/Newton, though I am not one definitely…

So this article gives a work around solution for many who use AA and are looking for their YEC process and have the same scenario. Apart from the work around, it also gives you all a little tip that whenever you are stressed at work, trying to figure out a solution, go have a break and I am sure your would get easy and fast solutions to issues which would have haunted you for a long time…

Until next post!!!

I have been involved in the process of reconciliation between the sub ledgers and the general ledger at various clients and there has been various scenarios in which there has been a break between the sub ledgers and the general ledger balances. A few key scenarios are quoted below

1. A transaction posted in the sub ledgers do not have a corresponding transaction in the general ledger. 
2. A transaction posted in the sub ledger is backed out/corrected at the general ledger level.
3. Manual posting to the sub ledger control accounts in the General Ledger.

In this article, I am going to provide some tips to avoid any of the above situations and ensure that there is data integrity between the sub ledgers and the general ledger. This will ensure that the periodic audits done in the system proceeds in a smooth manner to a great extent.

The first two errors listed above can be prevented by disabling the following options in the General Ledger setup window from Microsoft Dynamics GP >> Tools >> Setup >> Financials >> General Ledger. 

By unmarking the option “Deletion of Saved Transactions”, a journal entry batch that is created when a sub ledger transaction is posted, cannot be deleted at the General Ledger level. This prevents any deletion of a journal entry that was created from a sub ledger transaction. Note that if we have enabled “Post Through General Ledger” in the posting setup, this would not make a big difference, since whenever a transaction is posted in the sub ledger, the corresponding general ledger transactions get automatically posted as well.

By unmarking the option “Voiding/Correcting of Subsidiary Transactions”, the system will not allow us to void a journal entry batch that is created when a sub ledger transaction is posted. This prevents any voiding of a journal entry that was created from a sub ledger transaction. that if we have enabled “Post Through General Ledger” in the posting setup, this would not make a big difference, since whenever a transaction is posted in the sub ledger, the corresponding general ledger transactions get automatically posted as well. Further, this option will not allow the user to back-out (or) back-out and correct a journal entry that was posted for a sub ledger transaction.

The third error listed above can be eliminated by disallowing account entry for all the sub ledger control accounts like the GL accounts for Accounts Receivable, Accounts Payable and Inventory accounts, in the Account Maintenance window from Cards >> Financial >> Accounts, as shown below. We need to unmark the option “Allow Account Entry” for all the control accounts needed.

Unmarking this option for the key control accounts, will prevent the user from picking up this account in any transaction entry windows and will prompt the message as shown below.

This option will prevent any direct posting into the sub ledger control accounts in the General Ledger. All postings will happen only from the sub ledger module.

These options mentioned above are some key setups that we can enable in GP to minimize the data integrity issues between the sub ledgers and the general ledger which consumes precious reconciliation time which is spent by many resources during the key audit time.

Hope this information helps all.

Until next post…

I have been getting questions from many of my clients and network on the various levels of postings to the General Ledger accounts that are available in Dynamics GP. Hence I decided to provide some information on the same to all the folks in this community.

The level of posting to the GL accounts is determined from couple of setups working hand in hand in Dynamics GP which I will elaborate below. The initial setup is to define the level of postings for various accounts in the Account Maintenance window from Cards >> Financials >> Accounts as illustrated below.

We can specify the levels of posting from the various series into the General Ledger module. The various options available for posting levels are

• Detail
• Summary

Once this has been setup, we need to define the level of posting for various transactions in various modules in the Posting Setup window from Microsoft Dynamics GP >> Tools >> Setup >> Posting >> Posting as illustrated below.

So for the purpose of this case study, I created a couple of receivable invoices with the distributions explained below and saved them into a batch called RECVINV.

Invoice #1

Invoice #2

And I have setup the account 000-1200-00 to post at a Summary Level in the Sales Series in the Account Maintenance window, whereas I have setup the account 000-4100-00 to post in detail in the Sales Series in the Account Maintenance window.

Now, in the Posting Setup window, if we select the option to create one journal entry per transaction, posting will always be done at a detailed level (irrespective of the setting specified in the Account Maintenance window) (i.e.) There will be a one-to-one match between the distribution lines in the journal entry and the distribution that we had noted in the transaction posted in the sub ledgers.

So when the above batch RECVINV is posted in the Receivables module, there will be 2 journal entries created with the distributions explained below.

Journal Entry #1

Journal Entry #2

However in the above window, if we specify the option to create a journal entry per batch, we have two levels of roll ups that are available when journal entries are created when the sub ledger transactions are posted.

If the “Use Account Settings” option is unchecked, then when a batch of transactions is posted from the sub ledger module, the system creates one journal entry for all transactions posted in the sub ledger batch. However, there is no roll-up done at the account level, even though the accounts have been setup to post at summary level in the Account Maintenance window.

So in the same case study example above, if the batch was posted in the Receivables module, there will be one journal entry created with the distributions illustrated below.

Journal Entry #1

If the “Use Account Settings” option is checked, then when a batch of transactions is posted from the sub ledger module, the system creates one journal entry for all transactions posted in the sub ledger batch and the distribution amounts are rolled based on the posting levels for the accounts that are defined in the Account Maintenance window.

So in the same case study example above, if the batch was posted in the Receivables module, there will be one journal entry created with the distributions illustrated below.

Journal Entry #1

Journal Entry	Account Number	Debit (DR)	Credit (CR)
12345	000-1200-00	$1200	-
12345	000-4100-00	-	$500
12345	000-4100-00	-	$700

Note: Keep in mind that the various levels of postings will also be in effect only when we perform a batch posting in the sub ledger. If the posting is done at a transaction level, the system will always post in detail to the General Ledger (irrespective if the settings in the Account Maintenance window and the Posting Setup window for the specific sub ledger transaction).

Hope this article provides some insight into the General Ledger posting levels that are available in Dynamics GP.

Until next post…

Having used Analytical Accounting for quite some time now, I have come across various issues in Analytical Accounting module, which has caused serious data discrepancy between the General Ledger tables and the Analytical Accounting tables.

So I had decided to write up a simple SQL script to reconcile the balances for every account currency combination between the General Ledger tables and the Analytical Accounting tables.

DECLARE @ASOFDATE DATETIME
SET @ASOFDATE = '2010-05-16'
SELECT  DB_NAME() AS COMPANY,
        RTRIM(X.ACTNUMST) AS GPACCOUNTNO,
        X.CURNCYID,
        X.GLORIGAMT,
        X.GLFUNCAMT,
        X.AA30001ORIGAMT,
        X.AA30001FUNCAMT,
        X.AA30002ORIGAMT,
        X.AA30002FUNCAMT,
        CASE WHEN X.GLORIGAMT = X.AA30001ORIGAMT THEN 'TRUE'
             ELSE 'FALSE'
        END AS GLAA30001ORIGMATCH,
        CASE WHEN X.GLFUNCAMT = X.AA30001FUNCAMT THEN 'TRUE'
             ELSE 'FALSE'
        END AS GLAA30001FUNCMATCH,
        CASE WHEN X.GLORIGAMT = X.AA30002ORIGAMT THEN 'TRUE'
             ELSE 'FALSE'
        END AS GLAA30002ORIGMATCH,
        CASE WHEN X.GLFUNCAMT = X.AA30002FUNCAMT THEN 'TRUE'
             ELSE 'FALSE'
        END AS GLAA30002FUNCMATCH,
        ( X.GLORIGAMT - X.AA30001ORIGAMT ) AAG30001ORIGDIFFERENCE,
        ( X.GLFUNCAMT - X.AA30001FUNCAMT ) AAG30001FUNCDIFFERENCE,
        ( X.GLORIGAMT - X.AA30002ORIGAMT ) AAG30002ORIGDIFFERENCE,
        ( X.GLFUNCAMT - X.AA30002FUNCAMT ) AAG30002FUNCDIFFERENCE
FROM    ( SELECT    B.ACTNUMST,
                    B.ACTINDX,
                    A.CURNCYID,
                    SUM(A.ORDBTAMT - A.ORCRDAMT) AS GLORIGAMT,
                    SUM(A.DEBITAMT - A.CRDTAMNT) AS GLFUNCAMT,
                    ( SELECT    SUM(C.ORDBTAMT - C.ORCRDAMT)
                      FROM      dbo.AAG30001 C
                                INNER JOIN dbo.AAG30000 D ON C.aaGLHdrID = D.aaGLHdrID
                      WHERE     D.GLPOSTDT <= @ASOFDATE
                                AND C.ACTINDX = B.ACTINDX
                                AND C.CURNCYID = A.CURNCYID
                    ) AS AA30001ORIGAMT,
                    ( SELECT    SUM(C.DEBITAMT - C.CRDTAMNT)
                      FROM      dbo.AAG30001 C
                                INNER JOIN dbo.AAG30000 D ON C.aaGLHdrID = D.aaGLHdrID
                      WHERE     D.GLPOSTDT <= @ASOFDATE
                                AND C.ACTINDX = B.ACTINDX
                                AND C.CURNCYID = A.CURNCYID
                    ) AS AA30001FUNCAMT,
                    ( SELECT    SUM(E.ORDBTAMT - E.ORCRDAMT)
                      FROM      dbo.AAG30002 E
                                INNER JOIN dbo.AAG30001 C ON E.aaGLHdrID = C.aaGLHdrID
                                                             AND E.aaGLDistID = C.aaGLDistID
                                INNER JOIN dbo.AAG30000 D ON C.aaGLHdrID = D.aaGLHdrID
                      WHERE     D.GLPOSTDT <= @ASOFDATE
                                AND C.ACTINDX = B.ACTINDX
                                AND C.CURNCYID = A.CURNCYID
                    ) AS AA30002ORIGAMT,
                    ( SELECT    SUM(E.DEBITAMT - E.CRDTAMNT)
                      FROM      dbo.AAG30002 E
                                INNER JOIN dbo.AAG30001 C ON E.aaGLHdrID = C.aaGLHdrID
                                                             AND E.aaGLDistID = C.aaGLDistID
                                INNER JOIN dbo.AAG30000 D ON C.aaGLHdrID = D.aaGLHdrID
                      WHERE     D.GLPOSTDT <= @ASOFDATE
                                AND C.ACTINDX = B.ACTINDX
                                AND C.CURNCYID = A.CURNCYID
                    ) AS AA30002FUNCAMT
          FROM      dbo.GL20000 A
                    INNER JOIN dbo.GL00105 B ON A.ACTINDX = B.ACTINDX
          WHERE     A.TRXDATE <= @ASOFDATE
          GROUP BY  B.ACTNUMST,
                    B.ACTINDX,
                    A.CURNCYID
        ) X

This script is free for use and you can modify this script to suit your business requirements.

Note: I have updated the above script to validate the balances in all the 3 tables (GL20000, AAG30001 & AAG30002) to be in sync with one another. This is a critical enhancement since the AAG30002 table is the important table from where the data is picked up for reporting in AA.

Hope this script is helpful for folks.

Until next post…

In this article I am providing a script to delete the activity table records for a specific stranded user in Dynamics GP. This will enable us not to have all the users log out of GP in order to execute these scripts. This is typically handy when we have many users signed into the system from various regions and its a tough job to have all the users sign off the system for this maintenance to be done.

Note: Its always advisable to take a back up of the DYNAMICS database before you execute this script.

DECLARE @USERID CHAR(15)
DECLARE @CMPNYNAM CHAR(30)
 
SET @USERID = 'testuser'
SET @CMPNYNAM = 'Fabrikam, Inc.'
 
/*Deleting the user record from the DEX_LOCK table*/
DELETE  FROM tempdb.dbo.DEX_LOCK
WHERE   session_id = ( SELECT   SQLSESID
                       FROM     DYNAMICS.dbo.ACTIVITY
                       WHERE    USERID = @USERID
                                AND CMPNYNAM = RTRIM(@CMPNYNAM)
                     )
 
/*Deleting the user record from the DEX_SESSION table*/
DELETE  FROM tempdb.dbo.DEX_SESSION
WHERE   session_id = ( SELECT   SQLSESID
                       FROM     DYNAMICS.dbo.ACTIVITY
                       WHERE    USERID = @USERID
                                AND CMPNYNAM = RTRIM(@CMPNYNAM)
                     )
 
/*Deleting the user record from the SY00801 table*/
DELETE  FROM DYNAMICS.dbo.SY00801
WHERE   USERID = @USERID
        AND CMPANYID = ( SELECT CMPANYID
                         FROM   DYNAMICS.dbo.SY01500
                         WHERE  CMPNYNAM = RTRIM(@CMPNYNAM)
                       )
 
/*Deleting the user record from the SY00800 table*/
DELETE  FROM DYNAMICS.dbo.SY00800
WHERE   USERID = @USERID
        AND CMPNYNAM = RTRIM(@CMPNYNAM)
 
/*Deleting the user record from the ACTIVITY table*/
DELETE  FROM DYNAMICS.dbo.ACTIVITY
WHERE   USERID = @USERID
        AND CMPNYNAM = RTRIM(@CMPNYNAM)

I hope this script above would be useful to you folks…

Until next post…

How many times have consultants faced the situation where the system menu password in Dynamics GP is forgotten? This typically happens when we return to a client for an upgrade after about a year and it happens to be the case where the client side admin has forgotten the password as well…

Most of the time we handle this by deleting the record from the System Password Master table (SY02400) and then re-defining the password once more. But is there a way to recover the existing password without manipulating the data at SQL level? Fortunately, we do have an alternate solution and I am going to elaborate on the steps to recover this password, in this article.

When you have logged into Dynamics GP, go to Microsoft Dynamics GP >> Tools >> Customize >> Report Writer and choose the product as Microsoft Dynamics GP. This will open GP in the Report Writer mode as shown below. Click on the Reports button in the Toolbar.

Click on the New button in the Report Writer window and enter the following details for the new report that you have decided to create.

The report definition window would look as shown below.

Now click on the Layout button. Add the Password field from the System Password Master table into the Body section of the report as shown below.

Close the report and choose Save on the prompt that shows up.

Click OK on the Report Definition window to close the report definition window as well. Now you should be noticing the new report that we had created in the Report Writer window as shown below.

Select the new report that we had created and click on the Print button. On the Report Destination window, choose to print the report on Screen and click on the OK button.

The report will print on the screen and it will display the decrypted system menu password on the report as shown below.

Note: Note that in order to create this recovery report, we need to have access to this system series table, which is only available to users having the POWERUSERS role. Thanks to David Musgrave for providing this information.

This is an alternate method for GP administrators to recover the system menu password without having to delete the System Password Master table and resetting the password. Hope this article is helpful to all.

Until next post…