I've had several inquiries lately about how to create a "real time" integration between Dynamics GP and another system, and I've worked on several integrations over the last few months where clients wanted data integrated as quickly as possible.

I think there are at least three critical misconceptions around "real time" integrations, so I thought I would share some thoughts on the topic. By no means do I believe that I am "right" or that this is the only philosophy, but based on my experience and a few battle scars, I think my approach is pretty well grounded.

To give the discussion context, let's use an example. Acme Sales uses Dynamics GP, and a third party point-of-sale (POS) retail system. Dynamics GP is the system of record for all inventory items, and all item/site records. Whenever a user adds an inventory item to Dynamics GP, Acme would like to have that item automatically added to the POS system. Also, whenever a user adds an item/site record to Dynamics GP, Acme wants that information sent to the POS system so that the item can be sold at the appropriate stores.

During an initial meeting, the Acme sales manager tells the accounting and IT staff that as soon as either an item or item/site record is added to Dynamics GP, those records need to be transferred immediately to the POS system so that the item can be sold. The IT developer thinks "Okay, I'll create a real time integration between GP and the POS."

Naturally, the first thing the developer does is to put code on the Dynamics GP Item Maintenance window to detect when a new item is created. Simple, right? Just detect when the save button is clicked, and he can then immediately transfer the information to the POS. He then finds the Item Quantities Maintenance window and tries to put code there to detect when new Sites are assigned to Items.

He soon realizes that this approach may not work so well. Once a month, the sales department receives a list of 500-1000 new or changed items from one of their distributors. This list is imported into GP using an eConnect integration. Monitoring the Save event on the Item Maintenance window won't work, so he's not sure how he'll handle those items.

Next, while trying to put code on the Item…

Late last month, I was asked to assist a client who was having issues with the year end update for Dynamics GP. After I had helped her through the issue, she mentioned that she had an issue with Integration Manager that her previous consultant could not resolve. She had even gone so far as to completely wipe and reload the machine in an attempt to address the issue. Naturally, in the middle of a million year end questions, this issue actually sparked my curiousity :)

She showed me that on one machine, if she tried to run an integration, it would appear to start and then would display the error "Unable to load SanScript Library". Like any good consultant, I immediately checked the KnowledgeBase and found a few…

Recent versions of Dynamics GP have included terrific enhancements to 1099 tracking.  The ability to track 1099 amounts per type and box at a transaction level allows users to track in greater detail without having to assume that all of a vendor's payments go to the same 1099 type and box number.

Along with these enhancements, though, there are not a lot of great reporting capabilities to review this information by type and box.  Of course, you can inquire on the information easily (Inquiry--Purchasing--Vendor 1099 Details, Cards--Purchasing--1099 Details).

However, if we look at the 1099 fields available directly in SmartList, we will see that they are the "Amounts Since Last Close" summary fields. Which means that they are not date sensitive (they would be based on the last time you closed the calendar year for Purchasing), and they also do not include amounts by 1099 type and 1099 box although you can display the vendor's default 1099 type.  So, this may work okay if a vendor uses only one type and one box, and you are confident that you closed the Purchasing module on time for the prior calendar year and did not post back to the prior year or forward to the new year.

So, what about reporting?  Yes, you can print a report from Cards--Purchasing--1099 Details, but is only available for one vendor at a time.  In the past, I would tell users to print the 1099 edit list from Routines--Purchasing--Print 1099.

!--[if gte mso 9] ![endif]--
!--[if gte mso 9] Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 ![endif]--!--[if gte mso 9] ![endif]--!--[if gte mso 10]![endif]--

In recent versions, the ability of Dynamics GP to handle the most common 401(k) match scenarios has improved tremendously. But there are several pieces involved, so I thought it might be helpful to list them out here.

Take the example of a 50% match up to 5%. The employer matches 50% of the employee's contribution up to 5% of their gross wages. To accomplish this, you will need to set up both a deduction (to capture the employee contribution) and benefit (to capture the employer match).

First, set up the deduction (Microsoft…

This morning I fielded a question on Experts-Exchange about third party products for Dynamics GP 2010.  The customer was asking about inventory barcoding and warehouse management using Dynamics GP.

One of my recommendations to the GP customer was to consult with their GP partner to help them analyze their requirements and then get their help with reviewing the third party solutions.

To my horror, the customer replied:

"The GP partner in our area doesn't have any experience with GP 2010."

Aaaahhhhhh!!!!!!!!!!  Wake me up, I'm having a nightmare!!!!!

I don't know any of the details, but that statement alone tells me that something is very wrong.  If I take the statement at face value, it means that there is a GP partner out there potentially selling software that they can't support.  Interpreting further, could it mean that the partner is comfortable with prior versions of GP, but for some inexplicable reason thinks GP 2010 is somehow different or more complex?  That just doesn't make sense.

So without…

More and more, it seems like the answer to most Dynamics GP questions is "well, it depends."  It might depend on how much money you want to spend on services and/or software, or how much you care about a particular piece of functionality.  And, lately, it seems like I am getting a lot of questions related to tracking changes within Microsoft Dynamics GP.  Sometimes this is due to "damage control", or because a prior system had the capability, and in most cases I completely understand the concern and the request.  And, like I have suggested, the answer is not a simple one.  There are several options available to you, depending on how much time/effort/money you want to spend.

At the very basic level, GP offers a few inherent tracking tools, for example:

• Many transactions table provide tracking of the user who posted the transaction (not who entered it, but who posted it).  These fields are visible in Smartlist (Microsoft Dynamics GP menu-Smartlist), for Financial-Account Transactions the field is called User Who Posted and for Purchasing-Payables Transactions it is called Posted User ID.  Some records also provide a modified date, although it does not show who (Purchasing-Vendors, for example).
• With the Human Resources module, tracking is enabled in the form of a "reason for change" on pay and position changes.  This enables reporting of who, what, and why on the changes.  Although it does not track the before/after values (which could be inferred to some degree based on the change)  Depending on your configuration in Microsoft Dynamics GP menu-Tools-Setup-System-HR Preferences, entering a "reason for change" may not be required. 
• There are controls available for batch approval and posting permissions through posting setup (Microsoft Dynamics GP menu-Tools-Setup-Posting-Posting) and security setup (Microsoft Dynamics GP menu-Tools-Setup-System-User Security) to…

Ever had a Windows machine display the Blue Screen of Death?  Through amazing coincidence, blue screens showed up on both my desktop machine and a client's production Dynamics GP Terminal Server in the same week!  I got fed up with the cryptic errors and finally decided to learn how to diagnose the infamous BSOD.


A few months ago I built a new desktop machine. Although there were a few quirks with 64-bit Windows 7, it seemed to work well.  Until the day when I started to get the dreaded Blue Screen error.

Having dealt with blue screens occasionally over the years, my general interpretation is that once you start getting them on a machine, they don't tend to go away on their own.  Sure enough, my desktop started to blue screen a few times a week.

While at my desk, I saw the blue screen occur and flash on my monitors, but my computer instantly rebooted, preventing me from seeing the message.  By default, Windows 7 and Server 2008 are set to automatically restart when a "System failure" occurs.  This option is set under System Properties -> Startup and Recovery Settings.  The first change I made was to disable the automatic restart option so that I could know when the blue screen occured and see the error messages.

Sure enough, the blue screens showed up again a few days later, but unfortunately, the message displayed wasn't very helpful.




Sometimes you will get lucky and see a specific driver listed, like "ETRON_USB_3", which can tell you immediately that a third party USB 3 driver is causing the problem.

But in my case, since a specific driver wasn't listed on the blue screen, just a cryptic "STOP" error, I didn't have any clues as to a possible cause.  I figured that my only option would be to try and reinstall Windows, which isn't on my favorite-things-to-do list.  So I put it off and just ignored the occasional crash, knowing I would eventually have to deal with it.

Then, the other evening, while connected remotely to a client's server, I was suddenly disconnected.  When I was able to reconnect, I saw a message indicating that the server had experienced a blue screen and had restarted automatically.

Figuring that two systems with blue screens in the same week was too much of a coincidence, I took it as a challenge to learn how to diagnose the cause of the dreaded BSOD.

To my surprise, it turns out that it is shockingly simple to get diagnostic information about the BSOD error--if you know what tools to use and once you know how to use them. 

In the Startup and Recovery options in Windows, there is an option to "Write debugging information".  In the latest versions of windows, the default setting is to write a "Small memory dump", also known as a "minidump". 



When Windows encounters a "system error", it writes certain diagnostic information to this memory dump file explaining…

Trivia Question:  What is one of the fastest ways to spot a bad Dynamics GP .NET integration? (answer at the bottom)

I've seen some strange things in my days working with Dynamics GP and developing integrations.  I've seen several crazy GP macro generators that are used to "enter" data rather than using an integration tool.  I've seen .NET projects that are wrappers for the entire eConnect assembly, essentially re-writing all of the eConnect interfaces, for no apparent reason.  I've seen half-baked integrations that have transaction distributions hard-coded, with DR and CR going to the same account!  And I've seen the 1980s vintage integrations that used "technology" (and alot of duct tape) that was so old I didn't even know it existed.  All of these fall into the category of "What were they thinking???".

So when I was told that a client needed help with an existing VB-based integration, I thought "Excellent!", finally a modern .NET Dynamics GP integration.  Surely it will be well designed and use current integration tools.  And then I saw it.

Oh. My. Gosh.  How could I be more wrong?

So apparently back in 2006, the client's former "Gold Certified" Dynamics GP partner "developed" this ".NET" integration between the client's operational system and Dynamics GP.  It's really quite simple:  Import AR invoices and GL journal entries.  Piece of cake, right?

Fortunately, the client has a copy of the source code from their prior partner.  But when I start looking through the Visual Studio files, I don't see any code.  No classes and no modules--just a single VB form.  Hmmmm.

So I grab a copy of the entire solution and open it on my development server.  Sure enough, essentially no .NET code.  But what I…

Christina recently had the need to send notification e-mails to Business Portal users based on certain transactions that had been entered. To keep things simple, she was looking for a solution that could be implemented in SQL Server. After discussing it briefly, we were pretty confident that we could setup a simple routine to send e-mail from SQL Server. But there was a catch--we only had access to the user's Windows /Domain username in the SQL database, and we did not have the user's e-mail address stored anywhere in the GP database. However, the e-mail addresses were stored in Active Directory. So the search was on to find a way to access Active Directory from SQL Server.

It turns out that it is surprisingly easy to setup a simple SQL Server query that…