Dynamics GP 2010 Version List Heaven

To my surprise, the most frequently accessed page on our blog is the Dynamics GP 10 Version List.

Given the popularity of that version list, I wanted to post a follow up with the link to the Dynamics GP 2010 version list in Excel that is available on PartnerSource / CustomerSource.

It's mentioned in a single sentence buried on the GP 2010 Service Pack page (login required).

Here is the direct link to the Excel file (login required).

Note that the file has 9 tabs (as of Feb 2011) for the versions of Business Portal, Workflow, eConnect, and other 'products' related to GP.

How to Implement Dynamics GP Properly...And So Much More

Victoria Yudin, a Microsoft Dynamics GP MVP and owner of Flexible Solutions, has written an amazing book, Microsoft Dynamics GP 2010 Implementation, that is impressively comprehensive, detailed, and practical.

Back in 2004, I had a client who wanted to to have their internal staff help implement, configure, and support their Dynamics GP installation.  They essentially asked, "How do we learn everything we need to know about Dynamics GP?".  Naturally, the client didn't want to send several people to off site training, and wanted practical knowledge that the employees could immediately apply to their specific GP implementation.  I wish I would have had a copy of Victoria's book back then.  It is much more concise and practical than the dozens of GP user manuals, and vastly more efficient than attending two weeks of training to get up to speed with Dynamics GP.

Packt Publishing was gracious enough to send me a complimentary evaluation copy of Victoria's new book, and I am amazed at how much content she has packed into just over 300 pages.

The book is an excellent guide to the entire Dynamics GP implementation process--not just the installation, or configuration, or module specific features, but also the planning and design process that is essential to properly implementing GP.

Victoria starts with a concise overview of the Dynamics GP application, it's modules, licensing, and architecture--a great introduction to GP for a new user or consultant.

She then devotes three chapters to planning an implementation, covering business requirements, the implementation team, data migration, and project timelines.  A chapter is devoted to properly desiging the fundamental configuration of a Dynamics GP installation, including companies, the account framework, security, and key system and company setup records.  Another chapter covers a topic that is sometimes endlessly discussed during GP implementations:  the infrastructure that will be used to run GP.  If you are a GP consultant, how many times have you been asked about the GP hardware requirements?  Or whether GP should run on workstations or a Terminal Server?  Or whether the client can use virtual servers?  Everything from shared dictionaries to OLE notes, to database backups is also covered, all in specific and concise terms to help you implement properly.

The next 200 pages are devoted to installation, system setup, module setup, and data migration--a phenomenal amount of ground to cover.  Everything from Dynamics GP Utilities to vendor classes to UOM schedules to bank reconciliation is discussed, with tips and recommended settings, links to additional Microsoft resources, and an average of nearly one screen shot per page.

Obviously, Victoria couldn't exhaustively cover every possible Dynamics GP topic.  The book covers the "core" Dynamics GP modules, such as GL, AP, AR, SOP and POP, but doesn't cover the many other Dynamics GP modules available, as that would result in an encyclopedia.  And you will still need to know, or research on your own, what a SQL transaction log backup is or what a trade discount is.  And, of course, there is still alot of knowledge and expertise required to determine how many of the hundreds of Dynamics GP options should be configured to meet a specific customer's business requirements--which is why there are many GP partners and consultants available throughout the world who have spent years working with Dynamics GP.

But for anyone looking to have a single, comprehensive Dynamics GP handbook, I would strongly recommend purchasing a copy of Microsoft Dynamics GP 2010 Implementation.  It's a great, low cost investment to help you get more value out of your Dynamics GP solution.

You can purchase the printed book and eBook directly from Packt Publishing with free shipping, or from the usual outlets like Amazon.com and Barnes and Noble.

Learning Management Reporter Lessons the Hard Way

So, I thought I would put together a quick post on an issue that I ran in to today with Management Reporter.  It resulted in one of those 'doh moments.

When working with consolidated multi-company reporting in Management Reporter, it is apparently important that the account segments are named exactly the same in all companies that you plan to use with a selected row format.  Take the following example....

Company A
Account Structure: 4-2
Account Segment Names (Microsoft Dynamics GP>>Tools>>Setup>>Company>>Account Format): Main Account, Department

Company B

Account Structure: 4-2
Account Segment Names (Microsoft Dynamics GP>>Tools>>Setup>>Company>>Account Format): Main, Department

Do you spot the difference?  Company A called their first segment 'Main Account', while Company B called it 'Main'. Not a big deal, right?  Well, from what I can tell, it actually can be.  So, let's say you log in to Management Reporter in to Company A and build a row format based on 'Main Account'.  Well, if you notice, the row format will code the name 'Main Account' in to the row format. 

So, let's say you switch to Company B and open the row format you designed in Company A.  Uh-oh.  You will notice all of your main segments are missing from the row format. Ugh. And when you generate the report, no values will show for Company B even though the account structure is exactly the same.  But what is different?  The segment names.  Fortunately, it's an easy fix.  Just log in to Company B and change the first segment name (Microsoft Dynamics GP>>Tools>>Setup>>Company>>Account Format) to match Company A 'Main Segment'.  The row format will now display the main segments even when logged in to Company B, and even better the report will actually pull numbers for Company B.

Lesson learned- If you plan to use a building block for multiple companies, or for consolidated reporting across multiple companies, make sure your segment names match from company to company to maximize the efficiency of Management Reporter!

Upgrading an eConnect 10 Integration to eConnect 2010

I have had several clients upgrade to GP 2010, so I've had to upgrade several integrations to eConnect 2010.  I just upgraded 3 in the last week, so I thought I would document the general steps.  In this post, I'll cover the upgrade from eConnect 10 to 2010.  My focus is on the upgrade of .NET client applications that directly reference the eConnect assemblies.

If your eConnect .NET project is in Visual Studio 2005, I would recommend upgrading it to Visual Studio 2008.  I haven't had the need to install or use Visual Studio 2010 yet, but if you are adventurous, you could give it a try.

Before working on your .NET project, you will need GP 2010 and eConnect 2010 installed.  Note that eConnect 2010 is now available in a 64-bit flavor, so if you are installing on a 64-bit Windows machine, you have a choice of either version.  I haven't found any mention of the x86 vs. x64 versions in the documentation, so my assumption is that there isn't any specific benefit to either version.  On 64-bit machines, I'm currently opting to install the 64-bit version.

On to your Visual Studio project...

First, you will need to update your references to use the new eConnect 2010 assemblies.  Two of the eConnect 10 and 2010 assemblies have the same name (Microsoft.Dynamics.GP.eConnect and Microsoft.Dynamics.GP.Serialization), but the MiscRoutines assembly has been deprecated and its methods are now included in the main eConnect assembly.  Just delete your old GP 10 references, and add new references for the new eConnect DLLs located in the C:\Program Files\Microsoft Dynamics\eConnect 11.0\API directory.

Next, you will want to update your "using" directives to remove references to the MiscRoutines assembly if you are using it.  The GetNextDocNumbers and GetSopNumber classes in the new eConnect assembly replace the get doc numbers functionality of the MiscRoutines assembly.  Fortunately the GetNextDocNumbers methods are virtually identical to the GP 10 versions (the parameters don't have the same namespace), so using the new methods will only require minor changes to your code.

Finally, modify your eConnect import calls.  Instead of calling eConnect_EntryPoint, you will now call either CreateEntity (for master records) or CreateTransactionEntity (for transactions).  This does mean that you may need to have two different calls instead of the old single call, but everything else about the method call is essentially the same.

All of this is covered fully in the eConnect 10 Help file, so if you run into any issues during your upgrade, scan the help file to make sure you didn't miss anything.

My upgrades have gone very smoothly, only requiring changes to method names with no structural changes required.  Upgrading the Visual Studio project shouldn't take more than one or two hours for a basic integration.  However, make sure to reserve time for installing and configuring your GP 2010 development environment and fully testing your new integration.  I was able to get my integration code upgraded very quickly, but found that it could take over an hour to get my new GP 2010 environment configured exactly the same as my old GP 10 client environment so that I could properly test the integration.  Missing vendors, items, item sites, multi-bin, multi-currency, item currency decimals, GL accounts, you name it.  Once I had everything configured properly in GP, the eConnect 2010 integrations all worked flawlessly.

And before attempting to test, make sure that the eConnect 2010 service is installed and running.  This is the number one eConnect 2010 support issue I've had to deal with.  To help reduce those support calls, I've now added code to both check that the eConnect 2010 service is installed, and then check to see if the service is running.


        public bool DoesServiceExist()
        {
            ServiceController[] scServices;
            scServices = ServiceController.GetServices();
           
            try
            {
                foreach (ServiceController scService in scServices)
                {
                    if (scService.ServiceName == "DynGP11eConnect")
                    {
                        return true;
                    }
                }
                return false;
            }
            catch (Exception ex)
            {
                Log("An unexpected error occurred in eConn.DoesServiceExist: " + ex.Message);
                return false;
            }
        }
       
       
       
        public bool IsServiceStarted()
        {
            ServiceController sc = new ServiceController("DynGP11eConnect");

            try
            {
                if (sc.Status == ServiceControllerStatus.Running)
                    return true;
                else
                    return false;
            }
            catch (Exception ex)
            {
                Log("An unexpected error occurred in eConn.IsServiceStarted: " + ex.Message);
                return false;
            }
        }




Steve Endow is a Dynamics GP Certified Trainer and Dynamics GP Certified Professional.  He is also the owner of Precipio Services, which provides Dynamics GP integrations, customizations, and automation solutions.

http://www.precipioservices.com

Maximizing Garnishment Minimums

Why does it seem like there are a million different ways for different agencies to calculate garnishments?  As soon as I think I have a handle on one method, another method pops up.  The garnishments feature in GP seems to work well when an employee has a single garnishment, but I have found that multiple garnishments often times requires the Greenshades Garnishments module.

But, let's focus on what Dynamics GP can do (which can be quite a bit, depending on your requirements) out of the box.  Here are some requirements I encountered recently:

1. The first $150 of allowable earnings by the employee is not subject to the garnishment
2. If the employee earns between $150 and $200, the amount above $150 is garnished
3. If the employee earns more than $200, the earnings are garnished at 25%

Looking a bit closer, we could summarize this by saying that it is a 25% garnishment with a minimum net pay to the employee of $150 (what they must be left with).  For example, if they made $180, the garnishment would calculate as $45 (25% of $180).  But since there is a minimum net pay of $150, it would only withhold $30 (the difference between $180 and $150).  I have found it is critical to the configuration of garnishments to distill the requirements down to the simplest parameters possible.

So, how do we then set this up in Dynamics GP?  First, let's take the definition of "allowable earnings" or what might be called the wage base for the garnishment. In this case, allowable earnings is calculated as gross wages less taxes.  So, we can configure an earnings code to match this wage base (Microsoft Dynamics GP>>Tools>>Setup>>Payroll>>Earnings Setup).  This will control how the garnishment is calculated, beyond the standard options of Gross Wages or Net Wages. 

Next, we set up the deduction for the garnishment (Microsoft Dynamics GP>>Tools>>Setup>>Payroll>>Deduction).  We select a deduction type of Garnishment, and then select the appropriate Garnishment Category.  For the method, we can select "Percent of Earnings" and select the earnings code created above.  So, how does this differ from the "Percent of Gross Wages" or "Percent of Net Wages" method?  Let's take the following example:

Gross Wages = $1000
Taxes = $200
Deductions = $300
Net Wages = $500

Following our example, the garnishment would calculate based on the earning setup which was defined as gross wages less taxes.  So, therefore, the difference in the methods would be...

25% of Gross Wages ( 25% * $1000 = $250)
25% of Net Wages (25% * $500 = $125)
25% of Earnings (25% * $800 = $200)

Save the deduction you have created.  And then we have to establish the minimum wages the employee must be left with ($150 per the scenario we have described).  Now, for many people familiar with GP payroll, the impulse would be to put $150 in the minimum net pay field (Cards>>Payroll>>Employee>>Additional Info).  But, unfortunately, this field is minimum net pay AFTER deductions.  In this example, the $150 is the earnings that must be left (which does not include deductions).  So this employee has to be left with $150 before deductions.

To establish this sort of minimum, we can use the Garnishment Maximum Setup window (Microsoft Dynamics GP>>Tools>>Setup>>Garnishment Maximum Setup).  I select FED as the State/Fed code.  The key here is to select the same method (Percent of Earnings) and Earnings Code, and to stipulate a Max Withholding Percent greater than the percentage you plan to use.  Leave the Max Exempt Amount at zero.  Of course, if you have valid maximums, you can definitely stipulate them here.  But the field we are interested in is the Minimum Wage Rule Amount.  In that field, we put the $150 that the employee must be left with (prior to deductions).

When you assign the garnishment deduction to the employee (Cards>>Payroll>>Deduction), you can then select the Garnishment Maximum for Federal.  This will ensure that the $150 is left and not garnished according to the requirements discussed earlier.

Feel free to share any garnishment quandaries you have found yourself in and how you solved them creatively and I will update the post :)  Happy Monday everyone, have a great week!

Does More Always Mean More? Or Less?

I will admit I come from the "more is more" school of thought when it comes to information.  More information.  More detail.  More better.  But the fact is, particularly in larger volume situations, more can simply mean more to wade through.  More frustration.  More time.  Less better.

Let's take the case of posting in Dynamics GP.  In Posting Setup (Tools>>Setup>>Posting>>Posting), you specify the "Create a Journal Entry Per" setting.  If you select "Transaction", it is the equivalent of choosing to post in "detail".  Every transaction entered in the selected series and origin (window), will create a journal entry in the General Ledger.  So, for example, if you enter 10 invoices in Payables Management, you would end up with 10 journal entries in the General Ledger with 10 distributions to the Accounts Payable account and a 10 sets of distributions to expense accounts.

On the other hand, you can select "Batch" instead.  This would be the equivalent of posting in "summary".  Taking the same example as above, let's say you enter 10 invoices in to a batch in Payables Management.  When you post the batch, you would end up with only one journal entry in the General Ledger with one distribution to the Accounts Payable Account and one set of summarized distributions to expense accounts.

Well, great, you say.  But, you actually want a combination of these two methods.  You would like your expense accounts to post in detail and the Accounts Payable (or Cash or Accounts Receivable or...) account to post in summary.  We can do that too.  For the "Create a Journal Entry Per" setting, you can select "Batch" and also mark the "Use Account Settings" checkbox.  This directs the system to refer to the individual accounts to determine whether to post in detail or summary. 

If you choose this configuration, you must specify the "Level of Posting From Series" for your GL accounts (Cards>>Financial>>Account, Fixed Allocation, Variable Allocation).  There is a setting of "Detail" or "Summary" for Purchasing, Sales, Payroll, and Inventory Control.  For example, let's say that you would like your Accounts Payable account to post in summary and your expense accounts to post in detail.  So for "Create a Journal Entry Per", you select "Batch" and mark "Use Account Settings".  Then, you go to Cards>>Financial>>Account and locate the Accounts Payable account.  You would set the "Level of Posting From Series" to "Summary" for the Purchasing series.  So, when an entry is made in the Purchasing series that posts to the Accounts Payable account, it will be summarized by batch.  All other accounts with the "Level of Posting From Series" left at the default setting of "Detail", will post in detail.

On a side note, if you plan to configure this for your accounts, you can actually use the Mass Modify feature to update the "Level of Posting From Series" settings for a range of accounts.  Cards>>Financial>>Mass  Modify, and select "Update".

As always, let me know if you have any questions or want to share your own triumphs over the "more is more" or "more or less" mentality :)

** Keep in mind, when you select "Batch" for "Create a Journal Entry Per", the batch date will always be used as the posting date in the General Ledger.

Dynamics World 2011 Top 100 Dynamics Influencer Nominations

Dynamics World is hosting their 2011 nominations for the Top 100 Most Influential People in Microsoft Dynamics.

My blog-mate Christina Philips is already on the nominee list, as am I.  Of course prominent contributors to the Dynamics GP community such as Mark Polino, Mariano Gomez, Leslie Vail, Victoria Yudin, David Musgrave, and many others have also been nominated.

Make sure to nominate your favorite Dynamics GP "influencers" for 2011!

You can submit your nominations via e-mail, LinkedIn, or Twitter.

Unhandled Object Exception Access is Denied Party!

So today I encountered a rather odd situation.  The client was able to access GP, but when clicking on a home page or area page she would receive "Unhandled Object Exception" and "Access Denied" errors.   Other than "Access Denied", the "Unhandled Object Exceptions" would also say "Error Calling Method Save".  So it seemed to be a permission issue obviously :)

I found some references to errors with the home page being tracked back to the appropriate files not being found in the Backgrounds folder:
AreaPage.xsl

HomePage.css
HomePage.xsl
PreviewPane.xsl
So we checked it out, and the files were all in the appropriate location.  Dead end. 

But we did find that the user could not create a file in the C:\Program Files\Microsoft Dynamics\GP\Backgrounds folder.  But changing the permissions on that folder did not correct it.  So we check the plain ol' C:\Program Files\Microsoft Dynamics\GP folder.  Oddly, it had been set to Read Only as well.  So we changed both, and viola! the user can log in and access home pages and area pages successfully.

But this begs the question(s)....
1.  What are the true minimum permissions for the Microsoft Dynamics GP user directory?  A poll of coworkers said "Full Control" and I know that is what I have always done.  But is that true?  Could we get by with less (and appease many IT folks who would cringe at the "Full Control" notion)?
2.  Also, what would have changed the permissions for all users?  A gremlin?  A gnome?  Something had to change it, right?

So this post ends with more questions than answers, but I found it all interesting regardless so I thought I would share!