Page 1 of 17512345678910...2025303540...Last »

GP2015 R2 Upgrade – GP Utilities “SynchronizeTableData()” Error & Fix

This issue has already been reported and it’s also been addressed. I would like to post this still. To act more like a pointer. It’s quite crucial in nature.

I have been testing GP2015 R2 upgrade on my test environment when I faced the following error message:

Screen Shot 2015-07-27 at 6.10.32 PM

Quite evidently, upgrade didn’t go through after. I remembered this being posted on our GP Support & Services blog. Dug the post and got the solution.

Here’s the post: Known Upgrade Issues When Upgrading To Microsoft Dynamics GP 2015 R2

Please note that this has been fixed already and is available with June 2015 Update.


Filed under: #MSDYNGP, GP 2015 R2, GP Utilities, GP2015, GP2015R2, Upgrade

More here:
GP2015 R2 Upgrade – GP Utilities “SynchronizeTableData()” Error & Fix

July 27, 2015 · Vaidyanathan Mohan · No Comments
Tags: , , , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 11

Dynamics GP – Cashbook Bank Management (CBM) vs. Electronic Bank Management (EBM) vs. Bank Reconciliation (BR)

I have been doing a fair bit of explanation around Cashbook Management and Bank Reconciliation modules in GP over the past few weeks. I found the explanation from Brian Wick below was pretty good. To add on to his excellent explanation – here are a few additional items –

Cashbook Management –

  • Cashbook has support for more Multicurrency transactions. They can do bank transfers in as many as four currencies at the same time for instance whereas Bank Rec allows just two
  • Easier to track Tax with Bank Transactions (However, you should typically be using AR/AP modules in GP and let tax flow from there) . I’ve heard the argument from some customers that they have been told that this is the only way to track tax when accounting for GST or VAT. That is NOT correct! 
  • Support for more transaction types such as GL Checks and RM Checks with don’t really have a counterpart in the Ban Rec product
  • No eConnect Import Interface

Bank Reconciliation

  • More commonly Used, better and easier to support 
  • Works well and meets most requirements other than the 4 currency bank transfer requirement discussed above.
  • Has eConnect Import Interface

Cashbook Bank Management (CBM) vs. Electronic Bank Management (EBM) vs. Bank Reconciliation (BR)

(Bank Management (BM) refers to both CBM and EBM)

The major difference between Bank Management and the Bank Reconciliation is that the Bank Reconciliation receives most of it transactions from other modules. Debtors and creditors cash transactions are captured in RM and PM and Bank Reconciliation is updated accordingly.

You can capture all your cash transactions in Bank Management and RM, PM and GL will be updated accordingly. The windows updated in Great Plains are RM Cash Receipts, RM Transaction Entry (payments to debtors), PM Manual Payments, PM Transaction Entry (receipts from creditors) and GL General Entry.

However in the CBM transactions captured in PM transaction entry, RM transaction entry, SOP, invoicing and PM computer cheques also update CBM in the same way that Bank Reconciliation is updated.

The reconcile functions in CBM and Bank Reconciliation are very similar so the major difference between CBM and Bank Reconciliation is that Bank Reconciliation receives transactions from other modules and Bank Management is a single point of entry for all cash transactions. All other differences are in functionality: Batch processing, full multicurrency, Electronic Reconcile Management (Auto Bank Recon), Intercompany Payments and Deposits, Intercompany many to many Bank Transfers, Payments to Debtors and Receipts to Creditors ext.

The difference between the CBM/Bank Reconcile and EBM is due to the fact that in EBM you do not have any source documents (Cheque counterfoils, Deposit slips ext.) as 90% of the transactions are done via electronic transfer. So the first time we find out about a transaction is when it appears on the bank statement.

In CBM and Bank Reconciliation we capture our transactions from source documents (Cheque counterfoils and deposit slips) and then reconcile the transactions that are on the bank statement to the transactions that we have already captured.

In EBM we capture our transactions from the bank statement and then post the transactions to RM, PM and GL. As the source document is the bank statement there is no need to do a separate reconcile so the post and the reconcile is one process.

In EBM we do however allow for transaction that originate form counterfoils and deposit slips. When this happens the user will capture these transactions in RM and PM but instead of posting to the Bank Account the transactions will post to a Holding account. When the transactions appear on the Bank Statement they will be captured as normal and then matched to the original transactions in the Holding Account. Regardless of the type of the transaction (GL, AP or AR) EBM will create GL transactions moving the money from the Holding account to the Bank Account. Thus the Bank Account will only be affected by transactions that have appeared on a bank statement. By doing this the Bank Account will always have a true balance.

So the difference between CBM/Bank Reconcile and EBM is that CBM/Bank Reconcile are driven by source documents and EBM is driven by the Bank Statement.

Best regards,
Brian Wick
Partner Online Technical Community

See the article here:
Dynamics GP – Cashbook Bank Management (CBM) vs. Electronic Bank Management (EBM) vs. Bank Reconciliation (BR)

July 23, 2015 · Jivtesh Singh · No Comments
Tags: , , , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 12

#GPPT What’s New: GP Power Tools is faster and easier to navigate

David Meego - Click for blog homepageAs mentioned in recent posts, GP Power Tools is almost ready for release. The user guide manual documentation is now completed… all 256 pages of it. If you want to get the code now, you can already install the public beta and upgrade to the final release later.

This is the first article in a series of What’s New posts for GP Power Tools. The aim of this series is to highlight some of the new features of the tool and flesh out more details than the 21 reasons to upgrade article.

When creating GP Power Tools, one of the first changes (other than rebranding) was to change the data storage from a Debugger.xml setup file to tables in the system database on SQL Server.


A bit of history …. The Debugger.xml file was originally used to avoid the creation of any SQL objects to allow easy installation and removal of the Support Debugging Tool for its role as a troubleshooting tool. As the functionality of the tool grew and more data was stored in the Debugger.xml, performance slowed as the data was written to and read from the Debugger.xml file. To help with the read performance, ctree tables were used to cache the contents of the Debugger.xml. Also, the additional features added to the tool meant that the Debugger.xml needed to be stored in a shared network location. Finally, because the tool has lots more functionality than the original troubleshooting tool, it was being left installed on systems and the ease of removal was no longer important.

SQL Server

When creating GP Power Tools, one of the first changes (other than rebranding) was to change the data storage to use SQL Server tables. You would think that this would be a simple change, but it took about two weeks to complete. To make the Debugger.xml setup file work as a storage system required a large amount of custom code. The windows would read the Debugger.xml contents into temporary tables and then read and write from the temporary tables. When saving or applying, the data was written back the Debugger.xml file and the cache tables. All this code needed to be removed and replaced with more conventional code to use the SQL tables. To complicate the conversion, on some windows, data needed to be stored temporarily and only saved to the physical tables when applied. This meant that additional code was needed to store data in temporary tables until applied.

The end result is that when saving data, there is no longer a noticeable pause as the data is written. Also there is no requirement for a shared location to store the Debugger.xml file, however a shared location is still useful to centralize storage of log and export files. Finally, having the data stored in SQL Server is more secure than a shared location in the file system.


One of the areas of feedback received about the Support Debugging Tool was that it was difficult to find the options / windows. Part of the cause of this is that when new features were added, their navigation options were just added to the bottom of the Standard Mode or Advanced Mode features.

So GP Power Tools resolves this by providing multiple options for navigation as well as grouping the features. You can still find the main GP Power Tools Logging Control window on the Tools menus of the application and individual windows (both menu or ribbon style). The Ctrl-D keyboard shortcut is also still available.

GP Power Tools Menu   GP Power Tools Menu Ribbon   GP Power Tools Menu Window

You can also find the options on the Standard Toolbar and Quick links on the home page.

Toolbar    GP Power Tools Quick Links

From the main GP Power Tools window, you can use the Options button drop list or the GP Power Tools window menu to access other features. Both of these menus are now broken down with sub menus into functional areas:

  • Resources and Security
  • Scripting
  • Export and Import
  • Administration

GP Power Tools Options Menu 2   GP Power Tools Options Menu 3

GP Power Tools Options Menu 4    GP Power Tools Options Menu 5

Also, GP Power Tools has been added to the application level menus as a sub menu under Transactions, Inquiry, Reports, Cards, Setup, Utilities and Routines.

GP Power Tools Transaction Menu

Finally, GP Power Tools has its own Area page from the Navigation buttons: GP Power Tools Area Page Button

GP Power Tools Area Page Navigation

The Area Page means that navigation on the Microsoft Dynamics GP Web Client is now simpler.

Access to the windows is controlled by application level security and the four automatically created security roles:

  • GP POWER TOOLS USER – For Standard Mode (User) features
  • GP POWER TOOLS ADMIN – For Advanced Mode (Administrator) features
  • GP POWER TOOLS PASSWORD – For Administrator Password Setup window only
  • GP POWER TOOLS SERVICES – For GP 2015 (or later) Service Enabled Procedures

Note: Access to Advanced Mode features also requires sysadmin or dbo access at the SQL Server level and the System Password or Administrator Password (if enabled). The option to hide Advanced Mode features using a Dex.ini setting is no longer used.

So now you should have no trouble navigating the various windows of GP Power Tools by whatever method you decide.



This article was originally posted on

Filed under: 2010, 2013, 2013 R2, 2015, 2015 R2, Dynamics, GP, GP Power Tools, Microsoft, Products Tagged: GP 2010, GP 2013, GP 2015, GP Power Tools, GPPT

Originally posted here:
#GPPT What’s New: GP Power Tools is faster and easier to navigate

July 20, 2015 · WinthropDC · No Comments
Tags: , , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 25

#GPPT Installing the GP Power Tools Public Beta

David Meego - Click for blog homepageNow that the GP Power Tools Public Beta is out there, I know that people will not read the user guide documentation (GPPTools.pdf).

So I thought it would be worth while mentioning some guidelines to make the install as smooth as possible.

Firstly, let’s discuss the contents of the downloaded archive file. The archive contains the following files:

  • GPPTools.cnk

This is the self-installing dictionary containing the Dexterity code for GP Power Tools.

  • Debugger.cnk

This is a self-installing dictionary used for migration from the Support Debugging Tool. It is almost identical to GPPTools.cnk but uses the Debugger.* filenames.

This is required when the Debugger.dic file is already installed as extracting a chunk file will not update the launch file if it already exists. So this will overwrite the old dictionary file and then update the launch file to have the new names for the product and files. When Dynamics GP is restarted, everything now points to the new GPPTools.dic and the code removes Debugger.* files.

Only install this file if the Support Debugging Tool is already in the launch file.

  • GPPTools.txt

This is the read me file which version history information. Installation is optional.

  • GPPTools.pdf

This is the user guide for GP Power Tools. It must be installed if you want the application help system to be able to open the file.

  • License.doc

This is the license agreement for GP Power Tools which you accept by using the product. Installation is optional.

  • Application.GpPowerTools.dll

This is the signed Dictionary Assembly for the GP Power Tools Dexterity dictionary.

  • Application.GpPowerTools.xml

This is the IntelliSense data for Visual Studio for the GP Power Tools Dexterity dictionary.

  • Application.GpPowerTools.Metadata.dll

This is the signed Dictionary Assembly for the GP Power Tools Service Enabled Procedures. For version 14.0 or later.

  • Application.GpPowerTools.Metadata.xml

This is the IntelliSense data for Visual Studio for the GP Power Tools Service Enabled Procedures. For version 14.0 or later.

  • Addins/WinthropDC.GpPowerToolsVC.dll

This addin dll adds Visual C# support to GP Power Tools. Removal will disable the ability to execute Visual C# scripts.

  • Addins/WinthropDC.GpPowerToolsVB.dll

This addin dll adds Visual Basic.Net support to GP Power Tools. Removal will disable the ability to execute Visual Basic.Net scripts and execute Dexterity sanScript against modified dictionaries.


Use the following steps will install GP Power Tools:

  1. Copy the files to the Microsoft Dynamics GP application folder and the two dlls to the Addins folder.
  2. For the dll files, right click and select Properties and click the Unblock button if it is shown on the bottom of the first tab.
  3. Launch Microsoft Dynamics GP using Run as Administrator.
  4. If asked to restart after launch file changed, go back to step 3.
  5. Log into Microsoft Dynamics GP using a user ID with system administrator or DBO privileges, such as ‘sa’ or ‘DYNSA’.
  6. GP Power Tools will create its tables and read in the Debugger.xml file if upgrading from the Support Debugging Tool.
  7. You will be asked to assign security to all users, recommended to respond Yes.
  8. You will be reminded to manually assign security to the administrator level users.

Once installed, GP Power Tools can be accessed from the Application and window level Tools menus, the GP Power Tools area page as well as from the GP Power Tools sub menu on the application menus.

Disclaimer: As with all beta code, it is provided “as is” and you use it at your own risk.

If you receive errors from the two Addin dlls, they can be removed to avoid the errors. However the Visual C# and Visual Basic.Net functionality they provide will not be available. Please let me know if you have this issue.

Enjoy the beta and please provide feedback as comments on this post and via the survey built into GP Power Tools.


This article was originally posted on

Filed under: 2010, 2013, 2013 R2, 2015, 2015 R2, Dynamics, GP, GP Power Tools, Microsoft, Products, Support Debugging Tool Tagged: Beta, GP 2010, GP 2013, GP 2015, GP Power Tools, GPPT

Read More:
#GPPT Installing the GP Power Tools Public Beta

July 8, 2015 · WinthropDC · No Comments
Tags: , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 34

Error when trying to remove server roles in Dynamics CRM 2013

Error: Failure: The current user does not have required permissions (read/write) for the following Active Directory group: CN=ReportingGroup 94a899b0-954f-447d-86c9-7ac7bd0a081d,OU=CRM 2013,OU=Applications,DC=corp,DC=erac,DC=com Cause: The user does not have the required permissions. Solution: Provide Full Control permission for the user running the setup.

Visit site:
Error when trying to remove server roles in Dynamics CRM 2013

July 7, 2015 · Niran Belliappa · No Comments
Tags: , , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 25

Field Level Security can crash Microsoft Dynamics GP 2015 Web Client

David Meego - Click for blog homepageWhile working on testing GP Power Tools, I had to investigate an issue with GP Power Tools running on the Microsoft Dynamics GP 2015 Web Client, and discovered a bug which can crash the web client.

The problem I was seeing was just by having GP Power Tools installed, the web client would crash after login or when opening the first window. Note that this issue is resolved now.

I spent some time analysing the GP Power Tools code and tracking the flow of the scripts by adding warning statements into the code until I was able to narrow down the feature that was causing the crash.

Further investigation allowed me to identify the actual script causing the problem and finally, I was able to locate the actual line of code. The reason it was harder than normal to locate the issue was that the code in question was dynamically created pass-through Dexterity sanScript code executed in the context of the runtime engine’s Dex.dic dictionary.

To access more detailed dictionary resource information than available via the Resource_ function library commands, GP Power Tools and in particular the Resource Explorer window use the Script Explorer window in the Dexterity runtime engine. Dexterity developers will be familiar with the window which has part of the script debugger and is used when opening or debugging scripts.


The techniques using this window were published in my 2001 conference session Pushing the Limits with Dexterity. For more information see the Cross Dictionary Dexterity Development article on my old blog.

The error was caused by the line of code that opened the Script Explorer form in a script that would retrieve a list of windows for a specified form in a dictionary.

I knew that the Field Level Security feature included with Dynamics GP (which I originally developed as Omni Field Security) has a similar Resource Explorer window. So I tested that window and it seemed to work fine.

Then I noticed that my script closed the Script Explorer form before opening it and wondered if the issue was not opening the Script Explorer, but re-opening it after it had been closed.

The Resource Explorer window in GP Power Tools and the one in Field Level Security also closed the Script Explorer window when the Resource Explorer form is closed.

So I tested the theory and closed Field Level Security (and so the Resource Explorer and in turn the Script Explorer) and then re-opened Field Level Security (which opens the Resource Explorer and the Script Explorer) and boom. It crashed with the following error:

A server side exception of type “ArgumentException” has occurred.


I have since updated GP Power Tools to never close the Script Explorer window and just to initialise it when it is needed. This has resolved the crashing problem.

However, if you open and close Field Level Security and then re-open it, you can cause the web client to crash. It might not happen every time, but be aware that using Field Level Security more than once per web client session could be risky.

Note: While trying to reproduce the error to get the screenshots for this article, it took a few goes before the web client crashed.

If you are game, try it and let me know (via the comments) if you can replicate. Maybe it is just my install. If the session does crash, make sure you clean up the stranded session using End Task with Task Manager.


Also don’t forget to log back in as the same user and company to clean up the activity tracking records.


PS: I have also reported this issue to Microsoft and they will investigate it.

This article was originally posted on

Filed under: 2015, Dynamics, GP, Microsoft Tagged: Application, Exception, GP 2015

Continue reading here:
Field Level Security can crash Microsoft Dynamics GP 2015 Web Client

July 2, 2015 · WinthropDC · No Comments
Tags: , , , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 43

Welcome to the first GPUG Chapter outside of North America

David Meego - Click for blog homepagegpug-logo

I have been involved in GPUG (Dynamics GP User Group) over the few last years, primarily because I was presenting at conferences in the US which GPUG was organising or at least had a presence at.

As I learnt more about what GPUG does for the community, I realised that I wanted to bring the benefits of an organised user group to my home town in Perth.

So, after promising Kim “Mama” Peterson for a long time that I would start a Perth chapter of GPUG, I finally bit the bullet and booked a room at the local Microsoft Office and began planning our first meeting.

Last Wednesday night we had our first meeting with eleven attendees. We had representatives from four customer companies and two of the three local partners (the third partner gave their apologies and promised to be at the next meeting).


Before the meeting got started, we had some social time to chat and eat pizza. Free food… always a great reason to attend. :-)

My long time friend (and SQL Guru) Robert Cavill from Emeco presented a member showcase. It was the best member showcase we had ever seen (also the only one), but it should be the first of many.

I also gave a demonstration of the upcoming GP Power Tools product, showing how to use it to resolve a variety of security related issues. The demo included some of the features from its predecessor (the Support Debugging Tool), but also included some functionality newly added to GP Power Tools.

Thanks to Michelle, Katherine and Fiona from the Perth Microsoft office for their assistance and to Rose, Jennifer and Kim from GPUG for working with me to make this happen. Finally thanks to the local partners and customers who took the time out of busy schedules to come and attend.

The next meeting is scheduled for September. Exact details will be published later.

If you are a customer in Western Australia, we would love to see you at the next meeting.


PS: I found out that not only was this GPUG chapter meeting, the first in Australia, but also the first outside of North America.

This article was originally posted on

Filed under: GPUG, News Tagged: GPUG, News

Continue reading here:
Welcome to the first GPUG Chapter outside of North America

June 12, 2015 · WinthropDC · No Comments
Tags: , , , , , , , ,  · Posted in: Blogs I Follow Total Views: 59