GP 9.0 & Older Versions

Anything marked with a λ requires access to either CustomerSource or PartnerSource. If you have questions about accessing CustomerSource or PartnerSource, check out this post by David Musgrave and Scott Stephenson.

Share this:

Like this:

9 Responses to “GP 9.0 & Older Versions”

Great post regarding older GP versions. However, I tried accessing the GP 9.0 automated solution from customer source and it looks like they were removed. WOuld you have an archived copy of the GP 9.0 and GP2010 automated solutions? Appreciate your help.

Hi Victoria
I have a client who is on ver 9.00.281. He wants to upgrade to Gp 2013. I planned on following the upgrade path per Microsoft of course. The problem is he is running version 9 on SQL 2008. I dont know why or how he did it but my issues is that after applying the next service pack in the upgrade path. GP utilities does not have the option to update the database. We are trying this in a Virtual test environment first thank goodness. My question is are there any SQL scripts I can run to get the DB/Company updated so I can proceed? And if not what would your reccomendation be on how to get this done.

Unfortunately, GP 9.0 is not supported on SQL 2008 and in my experience, the upgrade will not work. You also cannot easily downgrade to SQL 2005. I would recommend contacting Microsoft Dynamics GP support to see if they can help you with this.

Hi Victoria. With Dynamics GP 9.0, we have created several company databases and continue to do so as needed.

With some of the lately-created companies, we see the following situation. When we use the ‘correct an existing journal entry’ function (i.e. Transactions -> Financial -> General, then Correct) we are seeing the following messages:

The stored procedure glpCopyJETToWork returned the following results: DBMS: 8144, Microsoft Dynamics GP:.

With older companies, though, this function works normally.

We are assuming that we have introduced a configuration problem of some kind somewhere. From the Dynamics interface, we have checked and compared the setups of older companies with newer ones and see no differences. It’s possible, of course, that the configuration issue is on SQL Server end.

This is not something I have run into before, but I cannot imagine what would cause this issue on any setup window in GP. From the error it sounds like you may have an issue with either the glpCopyTaxToWork or the glpCopyJEToWork stored procedure in the companies where you are seeing this error. I would maybe compare these between companies where you are not getting any errors and ones where you do to see if there is a difference. If so, maybe recreating them using a script from the companies where these are fine would be the way to go.

One of the main things that people often do not realize about tax calculations in GP is that taxes are calculated and stored individually for each line item on a transaction and then added up.

For example, let’s say you have a tax of 8.375% and 10 line items for $9 each. Each line item will have a tax of $0.75375 calculated. If you are rounding up, that will be $0.76 of tax for each line. Add the 10 lines and you will have a total of $7.60 in tax. However, if you take the subtotal of $90 and multiply it by the 8.375% tax, you will come up with $7.5375 or $7.54 rounded up.

I personally prefer to use the Round ‘To the Nearest Currency Decimal Digit’ on the tax setup instead of rounding up. With that setup in my example above you would have $0.75 on each line item and a total tax of $7.50. While still not $7.54, it’s closer to it and I believe over time it will come closer to the actual total of the tax if it were calculated using the subtotal each time.

All that said, I believe that worst case scenario in either case (rounding up or rounding to the nearest decimal) may result in fairly small differences in the total tax calculated each period, usually not enough to cause anything more than a minor annoyance and a small write off.