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.

9 Responses to “GP 9.0 & Older Versions”

Angie N Jon Reply October 1, 2015 at 1:29 am

Hi Victoria,

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.

Thanks,

Ruben

LikeLike
- Victoria Yudin Reply October 1, 2015 at 3:47 am
  
  Sorry Angie,
  
  I do not have these.
  
  -Victoria
  
  LikeLike
Vic Reply July 28, 2013 at 7:54 am

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.

LikeLike
- Victoria Yudin Reply July 28, 2013 at 7:57 am
  
  Hi Vic,
  
  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.
  
  -Victoria
  
  LikeLike
Bill Tonissen Reply January 9, 2012 at 10:27 am

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:

[Microsoft][ODBC SQL Server Driver][SQL Server] Procedure or function glpCopyTaxToWork has too many arguments specified.

and

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.

Is there anything you know of that might steer us? Thanks.

LikeLike
- Victoria Yudin Reply January 10, 2012 at 9:45 am
  
  Bill,
  
  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.
  
  -Victoria
  
  LikeLike
MARK Reply June 2, 2011 at 2:26 pm

Victoria,

We’re having issues with rounding of sales tax. Is there anything that better defines/describes/gives examples of the rounding options in GP 9.0.

In Oklahoma, “The tax must be rounded to a whole cent using a method that rounds up to the next cent whenever the third decimal place is greater than four.”

I’ve been using the “Round up to the Next Currency Decimal Digit” but we get variations were sometimes it calculates within a penny and other times it’s off by 10 – 15 cents.

Thanks for any help you can provide.

Mark

LikeLike
- Victoria Yudin Reply June 6, 2011 at 7:22 am
  
  Hi Mark,
  
  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.
  
  Hope that helps.
  
  -Victoria
  
  LikeLike