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.

GP 9.0

GP 8.0

GP – older versions and other links

7 Responses to “GP 9.0 & Older Versions”

  1. 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.

    Like

    • 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

      Like

  2. 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.

    Like

    • 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

      Like

  3. 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

    Like

    • 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

      Like

Trackbacks/Pingbacks

  1. Dynamics GP build numbers and service packs « Victoria Yudin - September 11, 2010

    [...] GP 9.0 & Older Versions [...]

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,532 other followers

%d bloggers like this: