Tag Archives: Dynamics GP

September was a whirlwind month for me, and it was also a steep learning curve month. I love learning new things, but I also hope to spare some of you the frustrations I encountered while delivering these solutions.

First, let me state emphatically that the internet is a wonderful resource. Let me temper that by stating that it can also be very confusing when you are looking for specific information and only find snippets of code and overviews of how “it should work”.  I have a fondness for examples and complete end-to-end documentation, and because I’m not a programmer I often find it difficult to make the leap to a complete solution by piecing together bits of script from various sources.

AA and Integration Manager

One of my customers has begun to use Analytical Accounting for simple project tracking. Of course, there is plenty of documentation on how to set up AA and distribute transaction amounts, etc. The challenges begin when you need to import AA data and prepare reports containing the AA detail information.

So in the interest of time, I am going to share the KB articles that explain in depth how to set up AA integrations.  These were provided to me by Microsoft, and they worked like a charm. Just right-click and choose “save link as” to download the PDFs.

AA GL Transaction

AA Sales Transaction

After reviewing the AA GL Transaction document, I identified the area where I had gone wrong in building my integration originally, and it’s now working beautifully.  If you are having trouble building an AA integration, I highly recommend that you follow this document step by step to understand how it works.  I will also clarify that my customer distributes to multiple dimensions and codes, so I had to tweak my source file to accommodate that requirement.  The AssignID on each AA code distribution has to be unique for the amount being distributed, not for the dimension or the code. Below are the actual examples from my test transaction:


***Now if I can just figure out how to dynamically assign the next journal entry number, this little project will be completed.  I hope one of you will provide me with a working example of the necessary scripts!***

AA and Management Reporter

One of the most critical components of any system is the output.  In fact, a lot of times when I’m discussing a customer’s needs, I will begin with “what do you want to accomplish by doing this?”  Normally in an accounting system, the ultimate goal of any data input is to view the information on a financial report.  Analytical Accounting information  is no different.  So it was with dismay that I realized the obstacles faced when trying to present these simple codes on an existing financial report.

First, my customers was using Dynamics GP10 and Frx.  When attempting to install the AA add-on for Frx, we discovered that it won’t run on a 64-bit server.  So we attempted to run it from a 32-bit workstation, but no luck was had there either.  I finally convinced the customer to move forward with their upgrade to GP2010 and Management Reporter, so we upgraded their databases and migrated their Frx reports to MR 20102.

I’m relatively new to Management Reporter, but I had some experience with the installation, configuration, and FRx migration process.  I now feel that I have mastered these steps,  thanks to some very helpful sessions at the  sold-out GP Technical Airlift in Fargo, which took place early in September.  By the way, if you are a partner or work for a partner, you should attend this event:  three days of technical information provided by the “in-the-know” folks at Microsoft.

With regard to the install and configuration, here is the link to the Microsoft download site.

Once I had Management Reporter configured and tested, it was a simple process to add a report to display the AA information.

Of course, much like the AA functionality in FRx, you have to be connected to the AA company in Management Reporter.  Beyond that, it’s a simple matter of adding the dimension codes in the row format like this:

When you double-click on the Link to Financial Dimensions, you will see the AA Dimensions as columns. Double-click on each one to define filters as needed.  In my example, I combined all expense types for each event on a distinct row, but you can use the dimension window to break out or combine codes as needed.

I’m sure I will be faced with combining the AA information with an existing financial report in the near future, so stay tuned for new adventures!

Leave a comment

September 29, 2012 · 8:19 am

WennSoft Troubleshooting for the Not So Faint of Heart

I have a couple of WennSoft customers in my fold, and they often pose some of the most challenging issues to resolve.  For those of you who are not familiar with WennSoft, you can find out more about their products here.  For those of you who are already – and reluctantly – aware of these add-ons, this post is for you.

GP service packs used to make me nervous, but they are almost effortless when compared to the issues I have encountered in applying WennSoft service packs.  Most recently, I took a customer from WennSoft Classic 2010 SP1 to WennSoft Signature 2010 R2 SP1.  This service pack contained 193 fixes to prior releases of the product and was compatible with GP 2010 build 1914.

I tried to anticipate (based on prior experience, of course) any obstacles that might come my way on a Saturday, when WennSoft support would not be available.  I requested and safely tucked away the new registration keys that I knew would be required; I requested additional information from WennSoft regarding any “gotchas” that might come my way and any additional downloads that might be needed;  I had the customer’s IT department download the appropriate files and place them on their server, and I double-checked the versions; I exported all modified reports for GP and WennSoft to package files; I backed up the GP code folder, etc. We planned a back-up schedule after close of business on Friday and I coordinated with IT to ensure that everything was ready.

After running the GP update Friday evening and verifying that it was error-free, I ran the WennSoft update utility.  As it was already late, I left that process running and went to bed.  Of course, in the morning I was greeted by a not-so-clear error message referencing a table that had updated sucessfully.  So after some research and pondering, I decided to give the update another shot.  It completed without error.  Yippee!

Unfortunately, my joy was short-lived.  I completed the update steps, took backups of the databases, verified that reports still worked, etc.  Then I notified the customer contact that the update was complete, so that she could do some testing before we updated clients.  This is all standard procedure, of course.  I had updated a single client and documented the steps so that the customer could complete the remaining workstations after testing.  I then moved on to deploying refreshable Excel reports, GP SRS reports and WennSoft SRS reports, and setting the necessary security for users to access them.

Monday morning we found out that the testing was not thorough enough. Users encountered errors when opening some windows, errors that indicated that tables had not been updated.  I’m sure you’ve seen this dreaded error message before: “Number of results columns doesnt match table definition.”  The customer contacted WennSoft directly for additional assistance and users continued to do their work in the system. We knew at this point that a rollback of 12 workstations and server would be quite time-consuming and that most of the system was operational, so my customer decided to trudge on.  A few hours later she received some guidance from WennSoft regarding a maintenance utility that would show us which tables did not update.  My response, of course, was to immediately run the maintenance utility, all the while wondering a) why does this not automatically run as a final step of the update process and b) why does it require a password?  Putting my frustration aside, I proceeded with the troubleshooting. There were 14 tables that were not updated. After another few hours of back-and-forth between my customer and WennSoft support, they offered to update the tables manually for a consulting fee. My customer asked if this was my recommended course of action, and I replied that I would do it for them, as I knew exactly what needed to be done to correct this error.

The answer was obviously to copy out the contents of these tables, rebuild the tables and associated stored procedures, then import the data back into the newly updated tables.  Fortunately, only six of the tables contained any records. The other ones were empty and could simply be dropped and recreated. I used the handy SQL maintenance window in GP to take care of this, beginning with the empty tables, then used the WennSoft utility to verify that the tables were at the correct version.  Three hours later, all the tables were rebuilt and the data back in place, and no further errors have been encountered in the system.

Harrowing experience? Yes! Rewarding? Absolutely!

1 Comment

Filed under Microsoft Dynamics