Tuesday, June 22, 2010

You NEED this book by Mark Polino!

This is an exciting year for all Dynamics GP partners and users!

The Microsoft Dynamics GP 2010 Cookbook is available for preorder.

This is a fabulous book covering so many tips and tricks that you will want it in your personal collection. Imagine, 400 pages of tips with step-by-step instructions on how you can take advantage of these unique topics.

My hat (pink with LED lights) is off to you Mark, great job!

Until next post!

Leslie

Change your Fiscal Period Names!

Fiscal periods should not be named Period 1, Period 2, Period 3, etc. These are the default names assigned by GP when new years are created. These names are editable and are easily changed just by typing into the field. Recording a macro to change the period names can make the job much easier and can be used year after year.

Access this window in the Administration Area Page in the Setup Content Pane, using the Fiscal Periods item in the Company menu.

The default period names

image

Better period names

image

These period names will appear in reports, range selections, and even FRx!

Until next post!

Leslie

Change your Account Segment Names

Account segments should have meaningful names. They should not be named ‘Segment1’, ‘Segment2’, etc. Turn them into relevant names using the Account Format Setup Window.

How it is now

So many look similar to this:

image 

The ‘Name’ field is an editable field. Type the proper name of the segment and many of the reports and views will have meaningful names.

How it can look

image

This change will cascade down to all of your range descriptions and inquiry screens throughout the system!

Until next post!

Leslie

Saturday, June 12, 2010

Taming the Accounts Lookup Window

Some features exist in Microsoft Dynamics GP that have been there ‘forever’, but are not given much attention. This post explores the ‘Include in Lookup’ option on the Account Maintenance window.

What’s the big deal?

The big deal is that when new accounts are created the default selections are most likely not the appropriate settings for your accounts, yet these selections are often left ‘as is’. Take a look at the familiar Account Maintenance window below.

image

Focus on the ‘Include in Lookup’ box, notice that all of the items are highlighted. I do not think this is the best setting for most accounts.

Restrict the accounts displayed

If you are entering a sales transaction, do you really want to see ALL of the accounts when you hit the lookup button on the distribution window? I don’t think so. For the accounts you do NOT want to display in the initial lookup window, simply remove that series from the ‘Include in Lookup’ option.

Here’s how it’s done

Open the Account Maintenance window. Select an account that should not be displayed in the Sales lookup window. Hold down the CTRL key and click on the Sales item to remove the highlight. 

image

Now, whenever the account lookup is selected in any sales series module, this account will not appear in the list. By using the View menu you can select to see all of the accounts, but this is an effective method to limit the initial choices presented.

There are several methods to limit the items that appear in a lookup window, but this one is often overlooked.

Until next post!

Leslie

Friday, June 4, 2010

Converting Security to v 10 – it’s OK!

Hi all,

I’ve heard a lot of buzz about converting security from earlier versions (8 or 9) to version 10. Most of what I have heard is “don’t do it”. I disagree. Do it, but understand the ramifications.

Why Convert?

The first (and only) ramification I can speak to is that you can get up and running more quickly by converting your current security than by completely re-doing your security using the new v 10 concept. In my world, if my clients had to re-do their security they would possibly never convert. Converting security to the new paradigm for a site with many users and many companies is an onerous task; and that’s putting it in a good light.

Making it Easier

Before you upgrade, you need to ‘skinny up’ your security such that you end up with the minimum number of tasks after the conversion.

For example, if you have 8 users and 6 companies, and each user has the same security for each of the companies he/she has access to, then after conversion each user has a task and role and Alternate/Modified Report ID for each company. Wow!  Don’t do that.

This recommendation came to me from Sheila Jefferson-Ross, an experienced (read over 15 years) consultant near Sacramento, California.

Before conversion, remove access from each company for each user who has the same security for each company. Whew, that’s another one where reading it again won’t help. Let’s look at an example.

Bob has access to three companies. His security is exactly the same for each company. If the conversion is done ‘as is’, then after conversion Bob will have a task for each of the three companies. Each of these tasks will roll into a role for each company. Multiply this for each user, and you end up with more identical tasks than anyone wants to manage.

In order to minimize the number of Tasks/Roles/Alternates, simply remove Bob’s access from two of the three companies before conversion. After conversion, grant him access to the other companies and copy the security from the first company to the other two.

You will end up with a manageable number of roles until the security is re-worked to embrace the v 10 model. Go ahead and convert! Version 10 has so many enhancements on v 9; don’t let the new security model slow you down!

Until next post!

Leslie

Making the Account Number SMALLER

We all know that we can increase the number of characters in an account segment up to the maximum number allowed in the Account Framework. However, if we need to REDUCE the number of characters, all of the documentation tells us we cannot.

Once upon a time there was not an option to display an expanded account width. Therefore, if you wanted to use an alphabetical character instead of a number, the alphabetical character would not be displayed if it was wider than a number. The only way around this limitation was to make the segment an extra character long.

After the ‘display width’ option was introduced, it was desirable to remove the extra character(s) from the account segment. All questions to Microsoft (then Great Plains) tech support said ‘NO’ you can’t do that.

Well, I’m here to tell you that you can!

Making it Smaller: Setting it up

First, you need to make sure that you do not have any characters in the position(s) that you want to reduce. For example, if you want to reduce a segment from 5 characters to 4 characters, then each of your accounts must not be more than 4 characters long in the segment you want to reduce.

If I want segment two to go from 5 characters to 4 characters, your accounts must include a blank character for position 5 of that segment.

Before account size reduction:
555-6588 –000

After account size reduction:
555-6588-000

Notice that the second segment includes 4 characters and then a ‘blank’. If your accounts are not in this structure, then you might want to invest in the Professional Services Tools Library’s Account Modifier/Combiner tool in order to align your accounts to the necessary structure.

Making it Smaller: Executing the change

Once your accounts are in the specified format, simply run the System Reconcile Utility (Microsoft Dynamics GP >> Tools >> Utilities >> Reconcile) against the Account Format Setup table.

The length of the account segment will be reduced from 5 characters to 4.

And they said it couldn’t be done . . .

Until next post!

Leslie

SmartList .ini switch Problems

What’s the switch?

SmartlistEnhancedExcelExport=TRUE

What’s the problem?

A client of mine was gracious enough to do some testing with this switch and discovered a couple of notable issues.

  1. Leading zeros are stripped from string fields when they are exported to Excel.
  2. The last digit of a string field is changed from a ‘2’ to a ‘0’. For instance:

Without Enhanced switch:

6055762161047502

Same record with Enhanced=TRUE

6055762161047500

I am not sure if it matters that there were two zeros in a row, but for now the switch is not usable for these types of fields. Using only numeric fields it is wonderful, but for string fields it seems to have issues. Like Patrick reminded us, it’s ‘undocumented’ for a reason.

Until next post!

Leslie